|
enki42 posted:I thought you were going to be really pedantic and say that sqlite doesn't have transactions. MySql doesn't? SQLite3 has transactions, but I'm pretty sure if you're using it you shouldn't worry about stability 'cause you should be able to rm and re-seed your database on a whim. MySQL is popular because Postgres used to be awful to run on Windows, back in the dark days when using Windows to develop PHP was reasonable instead of two terrible ideas for idiot retards.
|
# ? Jul 17, 2013 22:44 |
|
|
# ? May 15, 2024 03:53 |
|
Cocoa Crispies posted:MySQL is popular because Postgres used to be awful to run on Windows, back in the dark days when using Windows to develop PHP was reasonable instead of two terrible ideas for idiot retards. Wasn't Postgres really slow compared to MySQL for some time when the web was really taking off too? I can't really remember the reason why I chose MySQL. I only have MySQL now because of legacy junk. A document oriented database has been doing just fine for all my development since I moved to ruby/rails. I've never used ActiveRecord in production. I think I'm probably going to have to go back to a relational database here soon though. Whether I need lots of cross table correlation(i.e. reports) seems to be the determining factor for when to use a relational database for me.
|
# ? Jul 17, 2013 22:53 |
|
KoRMaK posted:Instead of writing that as SQL I would have written it as a ruby loop. Unless it's a very small amount of data that you are migrating, don't do this. Write SQL to do mass inserts and decrease your downtime. Also, I would suggest writing local classes to the migration to handle things that you may need. This way, if you ever change the classes in the codebase in the future, your migration will still work. MyClass.reset_column_information will reload the tables. Having to restart the server shouldn't be a huge issue because you're going to be running this migration in a Capistrano update task, right? Right?!
|
# ? Jul 17, 2013 23:48 |
|
kayakyakr posted:And your problem with saving is that params[training_plan_params] is not what contains the training plan properties. Take a look at what your server is telling you the params object looks like (also left in the quoted text above). That should also be a symbol or string, otherwise you're basically looking up params[undefined] or params[nil] which would also be nothing. I can't seem to figure this out, it seems like it should be working correctly. training_plan_params is a method: code:
Sorry for all the basic questions, and thanks in advance for the help! Edit - I am using Rails4 and Ruby2.0, Should I be learning in 3.2? The tutorials I am working with mostly use 3.1, but I wanted to mess around with the most recent versions. Newbsylberry fucked around with this message at 17:17 on Jul 18, 2013 |
# ? Jul 18, 2013 16:50 |
|
Newbsylberry posted:Edit - I am using Rails4 and Ruby2.0, Should I be learning in 3.2? The tutorials I am working with mostly use 3.1, but I wanted to mess around with the most recent versions. Learning in Rails 4 is fine.
|
# ? Jul 18, 2013 19:29 |
|
Does anyone have any examples of really well written/designed gems (ruby or rails specific)? I'd like to put a really solid piece of code up on github as a work example, and I want to make sure I'm following solid design patterns.
|
# ? Jul 18, 2013 20:42 |
|
How do you switch the version on api.rubyonrails.org? I need to look at an older version. Right now its stuck at 4
|
# ? Jul 18, 2013 21:06 |
|
I inherited a project that uses DataMapper, and I'm having some weird problems around Floats. Upon save any value gets rounded to the closest whole number. e.g 1.4 becomes 1.0, 2.8 becomes 3.0. I'm not altering the value at any point in the controller, just a straight form to save. It happens in rails console too. property :duration, Float, :required => true I tried futzing around with the scale and precision but to no avail.
|
# ? Jul 18, 2013 22:22 |
|
Newbsylberry posted:I can't seem to figure this out, it seems like it should be working correctly. training_plan_params is a method: As you pointed out, training_plan_params is a method. You want: code:
e: I was looking at the state of running background tasks and such. Right now it looks like the top two options for running anything separate the request thread are delayed job and resque, correct? Would I be daft if I made a gem that used thread pooling and ran background items (example: sending mails) in threads attached to the server instance? kayakyakr fucked around with this message at 23:45 on Jul 18, 2013 |
# ? Jul 18, 2013 23:42 |
|
KoRMaK posted:How do you switch the version on api.rubyonrails.org? I need to look at an older version. Right now its stuck at 4 Tack on v and the version you'd like, e.g. http://api.rubyonrails.org/v3.2.13/. I don't know what the hell happened to the switcher. The Milkman posted:I inherited a project that uses DataMapper, and I'm having some weird problems around Floats. Upon save any value gets rounded to the closest whole number. e.g 1.4 becomes 1.0, 2.8 becomes 3.0. Is it being persisted to an underlying column/field/whatever of the correct type? It's possible to end up with the database and model out of sync. If DataMapper can make a value reasonably fit the existing column type, it generally will. Molten Llama fucked around with this message at 01:21 on Jul 19, 2013 |
# ? Jul 19, 2013 01:09 |
|
Smol posted:Planned downtime is not a problem for this app. I know this is acceptable in a lot of sites but it always disappoints me when I see it. Deploying code and migrating data can almost ALWAYS be done without any downtime. It might take a few calls to db:migrate but it's drat good practice for when you're running a real site where you can't take downtime. We deploy code and migrations all day long without dropping any requests. No one wants to wait until 11pm for a scheduled maintenance window just to run some dumb schema migration.
|
# ? Jul 19, 2013 02:15 |
|
Molten Llama posted:Tack on v and the version you'd like, e.g. http://api.rubyonrails.org/v3.2.13/. I integrated SAML SSO today with Onelogin's kit. It wasn't that bad.
|
# ? Jul 19, 2013 02:30 |
|
Molten Llama posted:Is it being persisted to an underlying column/field/whatever of the correct type? It's possible to end up with the database and model out of sync. If DataMapper can make a value reasonably fit the existing column type, it generally will. Ahh, yes this must be it. Pretty sure this field was an integer at some point. I did run an auto_upgrade! while making some other changes, I would have figured that would take care of it. Alright, thanks I now know what to look into to
|
# ? Jul 19, 2013 03:17 |
|
dexter posted:I know this is acceptable in a lot of sites but it always disappoints me when I see it. Deploying code and migrating data can almost ALWAYS be done without any downtime. It might take a few calls to db:migrate but it's drat good practice for when you're running a real site where you can't take downtime. You're right of course. I try to avoid downtime in migrations where possible, but in this case, there will be downtime in a downstream API that we consume at the same time as we'll deploy the new version, so there will be some downtime no matter what. That's why I went for the simple solution. Anyhow, for anyone interested in no-downtime-migrations, check out these posts. Some good tips there. Smol fucked around with this message at 13:34 on Jul 20, 2013 |
# ? Jul 20, 2013 13:27 |
|
Is there anything I can do, or any reason for me, to try prevent users from entering dangerous stuff as, say, usernames and email addresses in my Rails 4 app? I know there's a sanitize helper for the views, and I guess I could just run input through that before creating a model, but I'm interested in validations for this. I guess the best I can do is write a custom validator with a regex that detects particular characters?
|
# ? Jul 22, 2013 07:03 |
|
Safe and Secure! posted:Is there anything I can do, or any reason for me, to try prevent users from entering dangerous stuff as, say, usernames and email addresses in my Rails 4 app? I know there's a sanitize helper for the views, and I guess I could just run input through that before creating a model, but I'm interested in validations for this. Yeah you should sanitize in your view and in your model. In your model you should be doing validations on any model before it's created. http://ruby.railstutorial.org/chapters/modeling-users#sec-format_validation
|
# ? Jul 22, 2013 07:15 |
|
Alrighty. Thanks!
|
# ? Jul 22, 2013 07:23 |
|
Safe and Secure! posted:Is there anything I can do, or any reason for me, to try prevent users from entering dangerous stuff as, say, usernames and email addresses in my Rails 4 app? I know there's a sanitize helper for the views, and I guess I could just run input through that before creating a model, but I'm interested in validations for this. What are you trying to protect from? Injection attacks? Setting values that they aren't supposed to be accessing? Any model changes (ie Model.create, Model.update) sanitize their values on setting them. The ARQI where method also sanitizes the values coming in. The "rails way" is fairly strong against injection attacks, just as long as you go through the sanitized methods. If you're worried about mass assignment problems, this is the new way to do it in rails 4: http://api.rubyonrails.org/classes/ActionController/StrongParameters.html You should validate, but I prefer to keep validation to business logic. Unless there's a particular attack or vulnerability that you're worried about, I'd suggest the same. In your case, this would be validating that it is a valid email and validating the uniqueness of the username and email.
|
# ? Jul 22, 2013 08:48 |
|
I was thinking primarily of preventing someone from sticking script tags in a username field, but I'd like to protect against whatever is feasible for me to be protecting from before sticking stuff into my database. Right now I have my User model validate uniqueness of names and emails. I also make sure the email has a '@', and I reject any name that matches /\W/ (non-alpha-numeric plus underscore), and I reject any email that matches /[!#\$%\^&\*\(\)-\+\=\_\?\|\[\]\{\}:"',\\\/<>]/. I realized that the ARQI method where sanitized queries, but I did not realize that AR's model-changing methods also did that. I guess there isn't much for me to worry about from a security standpoint, then, so I can focus my attention on validating rather than sanitizing input? So I can just get rid of the nasty email regex (which is probably wrong)?
|
# ? Jul 22, 2013 09:29 |
|
Safe and Secure! posted:I was thinking primarily of preventing someone from sticking script tags in a username field, but I'd like to protect against whatever is feasible for me to be protecting from before sticking stuff into my database. pretty much. Use any one of a million standard email regex queries that are on the net, but don't worry too much about having to sanitize every value that comes in, as long as you're using rails' standard methods to put that data in place. Though if you want to insult people trying simple injection attacks, that would be a good use of pre-checking.
|
# ? Jul 22, 2013 15:28 |
|
Can anyone suggest a way to test that there are no controllers in a rails app that respond to HTTP? Supposedly all HTTP requests are redirected to their HTTPS analogue, but I want to be sure...
|
# ? Jul 22, 2013 18:30 |
|
It's best not to worry about SSL on the Rails side and to setup a http-to-https redirect directly on your web server. It's also possible (but not recommended) do it with Rack::SSL, just set config.force_ssl to true on your environment configuration.
|
# ? Jul 22, 2013 21:17 |
|
You should also be setting a Strict-Transport-Security header via your web server since a 302 redirect from http->https can be a vector for man in the middle attacks.
|
# ? Jul 23, 2013 17:20 |
|
Safe and Secure! posted:Right now I have my User model validate uniqueness of names and emails. I also make sure the email has a '@', and I reject any name that matches /\W/ (non-alpha-numeric plus underscore), and I reject any email that matches /[!#\$%\^&\*\(\)-\+\=\_\?\|\[\]\{\}:"',\\\/<>]/. FYI: that regex will reject valid email addresses. Like kayakyakr said, use a good email regex from the web.
|
# ? Jul 24, 2013 16:40 |
|
Thanks for the SSL info Anveo and Smol.
|
# ? Jul 24, 2013 19:11 |
|
Lexicon posted:Thanks for the SSL info Anveo and Smol. For what it's worth, you can also iterate over all routes with Rails.application.routes and test that they return a redirect response to the same route.
|
# ? Jul 24, 2013 19:45 |
|
The best possible e-mail regex is:code:
|
# ? Jul 25, 2013 02:57 |
|
If you're thinking about getting too clever with your email regexes, go find some Qwest customers. And wear a cup. Tens of thousands of customers unable to use thousands of "clever" websites, including Fortune 500 retailers, major banks, and utilities, because Qwest migrated them to the (100% valid since 1993) q.com! Because domains can't be one letter, right? When in doubt: enki42 posted:send an e-mail to it. Molten Llama fucked around with this message at 03:51 on Jul 25, 2013 |
# ? Jul 25, 2013 03:45 |
|
That's great if you can send an test email to the user (e.g. a registration confirmation email). If not, I'll be more careful about it. Won't use any regex to do the validation though.
|
# ? Jul 25, 2013 09:02 |
|
Smol posted:That's great if you can send an test email to the user (e.g. a registration confirmation email). If not, I'll be more careful about it. Won't use any regex to do the validation though. how are you being more careful, per se?
|
# ? Jul 25, 2013 16:30 |
|
It looks like there's a gem for this, too https://github.com/kamilc/email_verifier It apparently goes through the motions of connecting to the appropriate SMTP server that would respond for that address, and confirming the address exists, without sending a message.
|
# ? Jul 25, 2013 16:57 |
|
Smol posted:That's great if you can send an test email to the user (e.g. a registration confirmation email). If not, I'll be more careful about it. Won't use any regex to do the validation though. You can use a regex. Nobody's saying don't use a regex at all—just don't cook up your own or try to be too restrictive. There are edge cases (like really short domains and really long domains). Standards change. TLDs multiply. If you're doing excessive validation, you're driving away customers who are now also angry. There's a reason today's "canonical" email regexes like the one Devise uses effectively amount to "is there one @ and at least one .?" That regex will work today and for years to come. The one that validates the length of a domain, or checks against a hard-coded master list of TLDs (yes, I've seen that), or requires all TLDs to be 3 characters, or declares uppercase characters to be verboten, or allows only one . in the domain is gonna have issues. (And even matching for a . will fail for some uses, but you probably already know if that's a design constraint.) Find a widely-used, permissive regex. Validate it against of variety of input. If an address doesn't feel right despite matching, don't dismiss out of hand—verify it through some other means, like a confirmation email where it's appropriate, or the gem kitten smoothie found where it's not. ThIs!{is}a$perfectly&valid^email=but_/many%regexes+will#fail~it@example.com. Several of those characters show up fairly frequently at large corporations. Or for an even more common, frequently-failed use case, the simple user+tag@domain.xxx. Fails crappy regexes all the time. Valid. Useful. Molten Llama fucked around with this message at 18:05 on Jul 25, 2013 |
# ? Jul 25, 2013 18:02 |
|
kayakyakr posted:how are you being more careful, per se? A real RFC 5321/5322 parser (should do RFC 6531 as well) plus MX/A record lookup. Smol fucked around with this message at 18:24 on Jul 25, 2013 |
# ? Jul 25, 2013 18:22 |
|
Smol posted:That's great if you can send an test email to the user (e.g. a registration confirmation email). If not, I'll be more careful about it. As somebody with a first-name last-initial gmail address, if you're collecting emails and not sending a double opt-in to them ("click here to activate this account"), gently caress you.
|
# ? Jul 26, 2013 19:28 |
|
Cocoa Crispies posted:As somebody with a first-name last-initial gmail address, if you're collecting emails and not sending a double opt-in to them ("click here to activate this account"), gently caress you. Eh, what's with the hostility? Not all websites can send email to registered users only.
|
# ? Jul 26, 2013 20:26 |
|
Smol posted:Eh, what's with the hostility? Not all websites can send email to registered users only. If you're collecting a list for any commercial purpose, you should be doing double opt-in.
|
# ? Jul 28, 2013 05:40 |
|
Molten Llama posted:You can use a regex. Nobody's saying don't use a regex at all—just don't cook up your own or try to be too restrictive. There are edge cases (like really short domains and really long domains). Standards change. TLDs multiply. If you're doing excessive validation, you're driving away customers who are now also angry. Pedantry that you're probably already aware of: checking for a dot is also unecessary; validations should only check for an "@". TLDs can have MX records, especially in intranets or with custom hosts files.
|
# ? Jul 28, 2013 17:45 |
|
xtal posted:Pedantry that you're probably already aware of: checking for a dot is also unecessary; validations should only check for an "@". TLDs can have MX records, especially in intranets or with custom hosts files. Exactly. http://ws
|
# ? Jul 29, 2013 01:09 |
|
Guys, email-based activation is really easy to do. I've done it so many drat times now with sorcery it takes 15 minutes of work and is totally worth it. Edit: And using the Mandrill SMTP servers you even get 12k messages per month free.
|
# ? Jul 29, 2013 01:39 |
|
|
# ? May 15, 2024 03:53 |
|
manero posted:Guys, email-based activation is really easy to do. I avoid confirmation emails because it kills conversion. Especially when you're trying to get less technical people to follow through. Ugh, the non-technicals.
|
# ? Jul 29, 2013 01:51 |