|
prom candy posted:Update Rack if you're using it, more security fun: http://rack.github.com/ What exactly is rack? I've read the overview page on github and I'm not really any the wiser.
|
# ? Feb 8, 2013 22:51 |
|
|
# ? May 15, 2024 01:09 |
|
From the Rack homepage:quote:Rack provides a minimal interface between webservers supporting Ruby and Ruby frameworks. Rack defines an interface that web servers and Ruby web application frameworks can use to pass HTTP requests and responses back and forth in a standard way. It's what allows things like Passenger to run both Rails and Sinatra applications. It also allows you to put functionality into framework-agnostic "middleware", (things like JSONP responses or cookie verification). As long as the web server and framework support Rack, they can interoperate. If you are using Sinatra or Rails, or just about any Ruby web app framework, you are probably using Rack. (Though you may not be using the affected middlewares: Rack::File and Rack::Session::Cookie). Novo fucked around with this message at 23:03 on Feb 8, 2013 |
# ? Feb 8, 2013 23:00 |
|
Physical posted:Does anyone here use carmen and carmen-rails? I am having a terrible time getting the demo app working. It looks like I cannot derive the country code from an official name, or I'm not calling it right. How are you using it? It's pretty straight forward: code:
|
# ? Feb 9, 2013 00:17 |
|
What's with the error I'm getting while trying to run this test? I was running 3.2.9 but went down to 3.2.3 like the tutorial does. It's from the Rails Tutorial by Matt Hartl http://ruby.railstutorial.org/chapters/filling-in-the-layout#code-user_pages_spec code:
/Library/Ruby/Gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/configuration.rb:746:in `load': /Users/robert/Desktop/shine/spec/requests/user_pages_spec.rb:9: syntax error, unexpected ':', expecting ')' (SyntaxError) it { should have_selector('h1', text: 'Sign up') } ^ /Users/robert/Desktop/shine/spec/requests/user_pages_spec.rb:9: syntax error, unexpected ')', expecting '}' it { should have_selector('h1', text: 'Sign up') } ^ /Users/robert/Desktop/shine/spec/requests/user_pages_spec.rb:10: syntax error, unexpected ':', expecting ')' it { should have_selector('title', text: full_title('Sign up')) } ^ /Users/robert/Desktop/shine/spec/requests/user_pages_spec.rb:10: syntax error, unexpected ')', expecting '}' it { should have_selector('title', text: full_title('Sign up')) } ^ from /Library/Ruby/Gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/configuration.rb:746:in `load_spec_files' from /Library/Ruby/Gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/configuration.rb:746:in `map' from /Library/Ruby/Gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/configuration.rb:746:in `load_spec_files' from /Library/Ruby/Gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/command_line.rb:22:in `run' from /Library/Ruby/Gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/runner.rb:69:in `run' from /Library/Ruby/Gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/runner.rb:10:in `autorun' from /usr/bin/rspec:23
|
# ? Feb 9, 2013 03:57 |
|
You're using ruby 1.8; the hash syntax in that spec is from 1.9. The 1.8 equivalent would beRuby code:
|
# ? Feb 9, 2013 04:04 |
|
You should install and use a 1.9.3 though
|
# ? Feb 9, 2013 09:15 |
|
Civil Twilight posted:You're using ruby 1.8; the hash syntax in that spec is from 1.9. The 1.8 equivalent would be Pardot posted:You should install and use a 1.9.3 though
|
# ? Feb 9, 2013 17:51 |
|
mmm11105 posted:I'm currently working on a webapp as a sideproject that I might want to launch, and I need some advice on hosting. As a poor student, I can't afford a huge monthly hosting bill to begin, as I have no idea if this idea will take off. So ideally I'm looking for hosting that can start real cheap but scale up if need by. Project is using postgresql. I'd avise taking some time to set up a VPS rather than going with cloud hosting. AWS and Heroku are great if there's a possibility for a sudden spike in traffic AND you can afford it. However, VPS hosting is way cheaper and you get a lot more bang for you buck, as far as single instances are concerned. Check out http://serverbear.com/ for benchmarks and coupons for different hosts. I have a couple servers with http://ramnode.com that are very fast thanks to the raid10 ssd's they use, and they routinely post 30%-40% off life time coupons on their twitter account.
|
# ? Feb 9, 2013 18:54 |
|
The $9/month database is fine for production on a small-scale site. I'm talking <10,000 uniques/month. Just remember to clear your long-running tables (sessions, logs, etc.) to keep yourself under 10m rows. In fact, start on the free database until you hit 10k rows. It'll work just fine. VPS hosting is only cheaper if you consider the opportunity cost. Do you know how to run a server and deploy a Rails application already? Yeah, ok, set up a VPS and deploy to it. If you don't know how to run a server then stick to Heroku or AppFog and spend those precious few hours you have writing code or marketing your site. You can always move to a VPS in the future if cost becomes an issue.
|
# ? Feb 9, 2013 19:13 |
|
Rails newbie here. I've got a rough alpha of my site done and just deployed it to Heroku. My user creation form doesn't work in production though. I I don't think it's a DB issue though. My problem appears to be in assigning the parameters. When I run this code on dev, it works; from production, it's telling me my required fields are blank. code:
EDIT: fml, forgot I disabled whitelist on dev. got it. Randomosity fucked around with this message at 23:54 on Feb 10, 2013 |
# ? Feb 10, 2013 22:57 |
|
You should keep your development and production environments as similar as possible to avoid this kind of bug hunting.
|
# ? Feb 11, 2013 00:11 |
|
tef posted:
If anyone that reads this thread is not subscribed to that loving mailing list, they're a loving fool. Do it.
|
# ? Feb 11, 2013 20:07 |
|
tef posted:
Must be Monday.
|
# ? Feb 11, 2013 20:07 |
|
It's every week now.
|
# ? Feb 11, 2013 20:10 |
|
I'm getting super good at scanning the platform. First time it took ~2 days to get notifications out. Last time it took all day. This time we got them out in just a little over an hour from announcement.
|
# ? Feb 11, 2013 20:49 |
|
On the bright side, these announcements keep a lot of our low-priority apps up to date. Someone on hacker news also mentioned this. Might be worth checking out in the future.
|
# ? Feb 11, 2013 22:50 |
|
Any suggestions for keeping dozens/hundreds of apps with vendored gems up to date? We're losing too many man hours and I get the feeling these security updates are going to keep coming.
|
# ? Feb 12, 2013 06:35 |
|
I noticed that with some of the prior vulnerabilities Postgres apps were not affected. Can anyone explain why that is? I'm a rails and pg noob and didn't even know how to phrase the search in google to find the reason.
|
# ? Feb 12, 2013 23:40 |
|
Sil posted:I noticed that with some of the prior vulnerabilities Postgres apps were not affected. Can anyone explain why that is? I'm a rails and pg noob and didn't even know how to phrase the search in google to find the reason. Some of the recent exploits are due to implicit conversions. Postgres is very strict about your data (which is an extremely good thing for a database), unlike mysql which does several (I'd argue irrisposiable, but I'm biased) conversions. http://grimoire.ca/mysql/choose-something-else is very thorough on what mysql does.
|
# ? Feb 13, 2013 00:32 |
|
As far as I understand, it's a combination of two things: Rails allows a user to specify the datatype that a parameter will be interpreted as while some databases (but not PostgreSQL or SQLite) do some implicit type conversions between things like string and integers. If you look at the metasploit module, they're telling rails that the reset_password_token parameter is an integer, while in reality, it's stored as a base64 encoded string. So if you have a base64 encoded string that starts with a number, like '9vaxNzzRWcUFTtyz7ydD', and you convert it to an int, you'll get 9. Or if it starts with a letter, as it most likely does, you'll get 0. So effectively, the attacker has just to guess the numeric prefix of the reset_password_token, which isn't very hard. In fact, with over 85% probability, the attacker can guess it on her first try. Dynamically typed frontend and a weakly typed db is a recipe for trouble. P.S. Does anyone know if the "strict mode" in MySQL will prevent things like this?
|
# ? Feb 13, 2013 00:33 |
|
You should migrate to god's* one true database. * Tom Lane
|
# ? Feb 13, 2013 00:47 |
|
Oh yeah. Just try executing a query like this with MySQL.code:
|
# ? Feb 13, 2013 01:05 |
|
Smol posted:Dynamically typed frontend and a weakly typed db is a recipe for trouble. Why does weak typing exist, like, at all? It seems to do nothing but cause huge headaches, often of the security variety.
|
# ? Feb 13, 2013 02:11 |
|
Pardot posted:Some of the recent exploits are due to implicit conversions. Postgres is very strict about your data (which is an extremely good thing for a database), unlike mysql which does several (I'd argue irrisposiable, but I'm biased) conversions. http://grimoire.ca/mysql/choose-something-else is very thorough on what mysql does. Thank you. Now I'm doubly glad I was using Postgres in dev/test/prod anyway, since I'm deploying to Heroku. e. weak typing in general exists for programmer convenience. Which of course goes out the window when you miss errors due to dumb automagic conversion rules that you never paid attention to. See also: Javascript. e2. actually my opinion on it is probably due to me sucking at Javascript. Here's an interesting article on typing in general http://blogs.perl.org/users/ovid/2010/08/what-to-know-before-debating-type-systems.html Sil fucked around with this message at 03:05 on Feb 13, 2013 |
# ? Feb 13, 2013 03:00 |
|
Great article. Interesting that the author basically considers the strong vs weak classification to be essentially meaningless. In a way, he's right, however I feel justified in calling a language "weakly typed", however pejorative, if it silently allows me to add an int to a string.
|
# ? Feb 13, 2013 05:19 |
|
Can someone tell me if I'm a complete idiot? We have dozens of apps running on a proprietary CMS. Our basic workflow is clone the CMS, delete the .git folder, re-init, and proceed as if it were a new project. All these security breaches have been a major headache because it means doing the "open project, update gem, bundle update, commit, push, deploy" thing over and over, which takes a lot of time. SO, the solution that we came up with was to move all the dependencies into an individual gem. The gem will be versioned based on the version of Rails it depends on, and then further based on any other changes to supplementary gems (ie JSON or Devise). For example, after all my mucking around today to get it working it's at version 3.2.12.8. When we clone the CMS into a new project it will just be set at the major Rails release point (ie "gem 'cms', '~> 3.2'). Next, we have a script that goes into each of our project folders and runs bundle update cms, followed by everything involved in a deploy. Is this crazy? Does anyone have any better ideas? I can't have my team spending the amount of time we're spending trying to keep Rails apps updated as it seems pretty obvious that the next few months are going to be painfully full of updates. Also, on a completely different note, is it possible to disable the auto sanitizing of all strings that got added midway through the 2.3.x branch? We have about 150 apps that are stuck at 2.3.5 because updating them would mean finding a million different places to type ".html_safe". In the meantime we've just been applying patches to our server version of 2.3.5 (thankfully NOT vendored into each project) but this seems unsustainable. Thanks guys, as you can probably tell I'm losing my mind a little bit over here.
|
# ? Feb 13, 2013 06:14 |
|
prom candy posted:Can someone tell me if I'm a complete idiot? We have dozens of apps running on a proprietary CMS. Our basic workflow is clone the CMS, delete the .git folder, re-init, and proceed as if it were a new project. All these security breaches have been a major headache because it means doing the "open project, update gem, bundle update, commit, push, deploy" thing over and over, which takes a lot of time. That's not very crazy at all. You're basically creating your own framework and bundling it all together.
|
# ? Feb 13, 2013 08:40 |
|
Anyone recommend a dyno/background scaler for Heroku? We are currently running the workless gem to manage our delayed_job actions. Our jobs are things like image processing, sending emails, site scrapes, etc. Workless is really fussy, and seems to die in production and spins up infinite copies of itself in development. The only alternative I know about right now is hirefire gem / hirefireapp.com.
|
# ? Feb 13, 2013 21:23 |
|
So I'm generally anti auto-scalers, I've seen them cause way too many problems vs the benefits. Are you trying to go from zero to nonzero when you have jobs to work, or like 2 workers to 10 if you have a lot of stuff? If you're mostly not doing work and don't want to have a worker on all the time, check out the scheduler add-on to run your job once an hour and then die. Or every 10 minutes. If you always have a few workers, fiddling with auto scaling doesn't really seem worth it, just find a good steady-state number to keep it at and maybe tune down at night and back up during the day, and use scheduler to do that. Another interesting pattern that we use for pgbackups is to use `heroku run` as our workers, and one process that runs all the time and monitors how many `heroku runs` are active pre job load. That's for a fairly high intensity workload though.
|
# ? Feb 13, 2013 22:12 |
|
We're going from 0 to 1 workers but on a half dozen different applications. I'm not crazy about an auto-scaler either, but the cost for leaving an idle worker up for 95% of a month just isn't worth it. Running tasks every 10 minutes is also pretty poor for users--I don't want a user to have to wait 10 minutes for their upload to be resized or for a password recovery email to be delivered.
|
# ? Feb 13, 2013 23:28 |
|
atastypie posted:We're going from 0 to 1 workers but on a half dozen different applications. I'm not crazy about an auto-scaler either, but the cost for leaving an idle worker up for 95% of a month just isn't worth it. Running tasks every 10 minutes is also pretty poor for users--I don't want a user to have to wait 10 minutes for their upload to be resized or for a password recovery email to be delivered. You can run more than one process per dyno—they'll share the same cpu and memory allocations. But for low use workers that might be a good approach. Just change your Procfile to start both.
|
# ? Feb 13, 2013 23:35 |
|
http://rapgenius.com/James-somers-herokus-ugly-secret-lyrics Well, this certainly explains all the random timeouts we've been seeing for so long.
|
# ? Feb 14, 2013 02:41 |
Will be interesting to hear Heroku's side. I'm sure they're formulating a response right now, replete with shiny purple diagrams.
|
|
# ? Feb 14, 2013 18:30 |
|
For what it's worth, their COO said that a blog post is incoming. http://news.ycombinator.com/item?id=5217818
|
# ? Feb 14, 2013 19:11 |
|
In Ruby, python, and other environments, I've tended to raise a NotImplementedError within methods that are intended to be implemented by descendant classes. Going by Stack Overflow, etc, this seems to be a common pattern, yet yesterday I happened to look at the documentation for that class and it seems like a flat-out inappropriate usage based on their description: http://www.ruby-doc.org/core-1.9.3/NotImplementedError.html Anyone have any thoughts on this? It's really not a big deal - whatever exception is raised it gets the point across.
|
# ? Feb 15, 2013 15:27 |
|
While that's what the docs say, NotImplementedError is used widely to implement abstract methods, including in the standard library. A separate smalltalk-like SubclassResponsibilityError might be the ideal way to do it, but from what I've seen, NotImplementedError is already the idiomatic way to do it.
|
# ? Feb 15, 2013 16:46 |
|
Smol posted:While that's what the docs say, NotImplementedError is used widely to implement abstract methods, including in the standard library. A separate smalltalk-like SubclassResponsibilityError might be the ideal way to do it, but from what I've seen, NotImplementedError is already the idiomatic way to do it. Cool, thanks for the explanation. That's what I thought - I was just a bit surprised to read that page.
|
# ? Feb 15, 2013 16:56 |
|
Smol posted:For what it's worth, their COO said that a blog post is incoming. They responded. quote:Yesterday, one of our customers let us know about significant performance issues they have experienced on Heroku. They raised an important issue and I want to let our community know about it. In short, Ruby on Rails apps running on Bamboo have experienced a degradation in performance over the past 3 years as we have scaled.
|
# ? Feb 15, 2013 21:07 |
|
|
# ? May 15, 2024 01:09 |
|
So it seems like they apologized for not communicating how things work, but there's no mention whether or not their "new" routing is going to be changed. Which probably means that it won't. Don't get me wrong, I think that their damage control at this point is actually a good thing; I'm just not sure if I want to continue using their new routing mesh.
|
# ? Feb 15, 2013 22:03 |