I'm using the devise authentication plugin under rails 3. At the moment, I have disabled the email confirmation, so that sign up is really easy and fast.
I'm wondering if some kind of captcha is necessary to protect the site agains bots. I would like to avoid having my database filled with fake users, although this couldn't do much harm to the system (except filling up the disks!).
If a captcha is strongly recommended, is it also true if sign in/up is restricted to HTTPS? Do bots use HTTPS?
i think it's a necessary evil. Wish we didnt have to use it but we dont live in an ideal world. Image twirly captcha is definitely not aesthetically nice and should really be avoided.
I think you need to be flexible about captcha and the kind of captcha you use. The strategy will and should evolve.
Initially when you dont have many users, you may avoid captcha altogether. Once things start picking up steam and you start seeing bots in the system, go for inivisible captcha (or reverse captcha). Reverse captcha basically relies on certain field NOT being filled by humans to identify humans (put a field which humans cant see on the form by making it invisible using css; bots will find that field, fill it and if the fields comes filled you know its not a human; a honeypot field if you will).
Eventually when you site becomes really popular, and a target for bots, you'll go for harder captcha which wont be easy to break but users might overlook it in order to signup to your very-very-popular site.
So start with no captcha and then evolve.
I don't see how bots couldn't access pages that uses SSL, so if you want to avoid bot users, add the captcha or activate the email confirmation. An alternative (if you want to make sign up/sign in) really, really easy could be to use OmniAuth (which is also supported by Devise).
I'd recommend a CAPTCHA, it's a good bot filter for not that much work; if you're worried about its effectivity, use reCAPTCHA - it seems to be reasonably resilient and integrates well.
As for HTTPS bots - if they don't exist now, they will in a few months (as more sites are considering HTTPS in the wake of FireSheep).
Related
I have a Rails-based API that has successfully integrated Devise. One remaining question I have is how to handle emails (confirmation and reset password). Devise automatically sends out these emails with links to its views. Since the API shouldn't handle views, what's the best way to deal with this? My questions are:
Is it inevitable that the API would contain some html templates since Devise sends out these emails? Is there a way for these templates to be on the client side?
How do I do with the links, which contains information like confirmation tokens and reset_password_tokens? I am not well-versed in client-side tech but should the links point to the client side's domain so that it can capture, rip out the tokens and make the calls in the background?
Thank you.
I've used Devise for a few API-only Rails projects. Frankly, IMHO, Devise is too heavy an opinionated for such projects. I love devise, but there's a lot of magic and assumptions. One of the assumptions is that you'll be using traditional Rails views. This isn't what you asked, but FWIW you might check out some other authentication libraries, like https://github.com/thoughtbot/clearance.
1) I don't see a way for your client app to have an email template. This action is happening entirely outside your client. Rails is sending emails, which your users then view using their email client (I'm assuming your client app isn't actually an email client).
I think the Rails api is the proper place for email templates in this case. I cannot think of a way that you could involve your client app in this. Even if you could, why would you want to do so?
2) There are a few ways to handle the links to password resets. The first thing you could do, as you state, is simply to grab the data and write your own views. But that seems like quite a lot of work, and you might end up fighting a lot with Devise.
An easy solution is to just let Devise own this stuff, and use Rails views. It's messy, but simple and easy. Devise is very opinionated, and this is the path of least resistance. It seems to me that you are trying to swim upstream here, based on a principle of separation of concerns. I'd argue that using Devise makes it very difficult to do that.
If you really must have your client app render all views, including ones for this feature, then you might consider just rolling your own password reset feature and keeping Devise out of the mix.
I am building a website for a client that wants to be able to make edits to things on their website. As such I need a way to allow the client to login to the site to make their changes.
My initial thought was to make an authentication system that relies on a User table in the database that is capped at one and only one user. It seems sort of overkill however to make a database table for just one result, so I was wondering if there were any other approaches or best practices that anyone could point to for building a site with just one user.
You could simply authenticate with a static password that is received from a file(encrypted), if you do not want a db model for that.
However, setting authentication with a gem like Devise is like 10 minutes of work. In order to be more secure(it can be a matter even in single user apps), you can set it up and be fine :)
I would highly recommend you set up authentication. As SpyrosP said it does not take long when you use Devise.
I am trying to configure an application for my client and I am using recaptcha for spam control and I am using ruby on rails (also using this plugin http://github.com/ambethia/recaptcha/).
My client wants an easy challenge as he is not able to read, its too hard. Is there any way I can make the challenge easier?
ReCaptcha is a third-party captcha, and I don't believe they give you any control over what captchas they serve.
It is true that a big complaint people have about captchas is that they can be hard to read, but if they were easy to read, they would also be easy for spammers to get past. You really can't win. :(
The good news with recaptcha in particular is that often you only have to get one of the two words right to pass the test, and it's usually the easier-to-read one. If you give your best effort with the other one, recaptcha will often let you through. (see the recaptcha site for details of how it works and why this is the case)
One solution might be to use some logic questions instead of confusing captcha images. There is a plugin for this.
I'm looking to build an application that handles authentication and authorization for a variety of smaller apps that may or may not be rails applications (e.g. some with sinatra, some with non-ruby frameworks, etc). These applications will be on separate domains.
Can I do this with Authlogic? I do not want to setup a rails application for each application, just use a central authenticator. I'm sure as I start reading and working the answer would become evident, but I'm trying to avoid a dead end (doing work and research, then finding out this can't be done.)
From what I've read this is a use case, and I'm looking for input from people who've done similar. This is at the idea stage so if i can offer more detail, let me know.
I think you are planning to build a cross domain, single sign-on service. Besides building your own, there are a quite a few project that do this out of the box.
rubycas is one of them : http://code.google.com/p/rubycas-server/
You could also look into open Id (http://openid.net), where the login functionality is done by a third party authentication server.
In case you want to roll your own:
It doesn't really matter which authentication plugin/system you will use. (I would choose devise/warden, but Authlogic will do just fine). Instead you need to focus on understanding the security problems and the http interaction between your service, the browser and the application for which authentication is used. I think it's doable, but you need to know what you are doing.
Today, the cool kids use warden, or the railsy thingy devise.
Im not sure but i think you cant use authlogic with a non-ruby-app.
I would probably go with Devise as well but you should look into some plugins for it like JanRain's Engage (used to be RPX Now). It allows you to use quite a few social login options (Facebook, Twitter, etc.) http://www.janrain.com/products/engage.
Ryan Bates from Railscasts.com just posted an episode on Devise using Engage this morning. http://railscasts.com/episodes/233-engage-with-devise
There are some more episodes about Devise on Railscasts too. http://railscasts.com/episodes?search=devise
If I were you I wouldn't reinvent the wheel. I'd use a third party service to authenticate and just get on with the project. Social connectors such as Engage will provide this functionality for you without all the time and expertise.
I've managed to setup authlogic, and quite nice it appears too. Is it secure enough out of the box?
I haven't really configured it too much. I'm going to be using it on a school website where the headmaster basically logs in with username and password to edit notices on the website. So it needs to be secure, but it ain't a bank or an e-commerce site or anything.
All I've done is restrict access to all the edit pages so you need username password and was going to leave my security at that. What do you think?
Restrict access to new, create, edit, update and delete (so only show actions are 'in the clear').
Other than that, I've never come across mention of any Authlogic security issues with a default configured Authlogic setup. Most of the configuration options are provided for dealing with specific requirements imposed by certain environments rather than something that is required for clean environments.
Be sure to add functional tests to ensure that anyone who is not logged on cannot do new, create,edit,update and delete actions. The beauty with tests in this situation is that sometimes they weed out things you may have missed in the initial coding.