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.
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.
This question aims to understand RoR and frameworks in general. It looks like RoR never had any standard user authentication system. Was it just historical reason (just happened naturally as it did)... or could it be intentional? Because RoR is a website building tool, more often than not, user authentication is a crucial part of a website.
To put it into perspective, another question is, do other popular frameworks, Django, Symfony, CakePHP, have user authentication built in?
There is no reasonably generic way to do user authentication. Most frameworks leave it up to you to choose the plugin that most closely matches what you're trying to accomplish.
For example, consider these two situations:
a blog which has a single administrator with password-protected admin-facing tools
a site like YouTube which allows users to sign up and administer their own content
Both of these sites would require vastly different authentication systems; which of these systems should Rails cater to out-of-the-box?
The Rails core team wanted to ensure that Rails was open-ended enough to make anything you want. There is no one-size-fits-all authentication scheme, so the core team decided to leave it out. Rails is easily extendable via gems and plugins, so that is where they belong.
Some examples are Warden and the Rails Warden plugin, Devise, Authlogic, and Restful Authentication.
CakePHP has a built in Authentication component that is pretty straight forward and easy to implement.
Most of these frameworks you mentioned are toolkits, not complete products. You build these things yourself, or leverage plugins from the community. Django's admin plugin/module has authentication out of the box though. Drupal does too, as a matter of fact.
Authentication can be(and is in my opinion) a matter of taste and need. If Rails was including things like that, it would start to become a website and not a framework. The programmer has to be free to choose among various implementations. That is why gems are available.
I've been programming a little in Rails and CakePHP, and I can say that Rails doesn't need to provide a mechanism like this. The community is very very good, and there are many examples (already said, like Devise, Authlogic...) made by very good programmers. Of course, there are many tutorials online (and also, railscasts, which are simply awesome) to program a succesful set-up for your project. So, if we have all of this, why should we need something like cakePHP mechanism? It's OK, it works, but there's just a very good tutorial and that's all( and maybe enough..). So, in the end, if u have a nice community you shouldn't care about the core of the technology, there will be always someone else more experienced with your needs that will do it for you. And if you don't find it, do it by yourself and in the proccess you will find a lot of help! :)
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).
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.
Does anyone know of a plugin or something that can be used to send bulk emails for a Rails app?
Specifically, I'd like to be able to pass an HTML email file to a rake task or something and have it emailed out to everyone who has signed up to my site and checked the "please send me info about XXX" box.
I wrote kind of a hacked-together version for myself, but I'd like something that throttles itself somewhat smartly and can pick up where it left off if interrupted.
Update: I eventually broke down and got out my credit card and signed up for a real bulk email service, and damn was that the right choice. The resulting emails are very professional, they have built-in analytics, also integrate with Google Analytics, and it's awesome for a ton of other reasons.
If you're looking to do bulk emails with Rails, I would suggest using the Mailchimp service (here's my affiliate link that has a bonus on signup) along with the hominid gem. This will allow you to sync all your user emails from your database to Mailchimp, then use a real bulk service instead of some crappy patched together one.
Another Update: I heard about Maktoub today, and it's pretty much exactly what I was describing. Disclaimer: I have never used it and would still probably steer clear and go with a paid service, but it's still probably better than rolling you own.
I couldn't find one so I wrote it myself. It's not pretty (at this stage), but should serve as a good starting point for anyone with similar needs.
Please send me a pull request if you make any beneficial changes and I'll make sure to give you credit.
Mailcar - Ruby on Rails mass / bulk email plugin
Update - I highly recommend using a service. Rolling your own is a real pain and it will be difficult to manage once your list becomes reasonably large at all.
I don't know that this is the kind of thing that can be covered by a plugin as there are whole sites/applications dedicated to this kind of thing. If you wanted to use one of those then there is www.campaignmonitor.com, it's pretty good and it has an api that you can hook into from your application.
You might want to take a look at postageapp.com
Not aware of any plugins for this and I don't know how rake could be used to do this, if at all.
Since you're using Rails, I assume you're using MySQL as your database so this may not be useful to you, but SQL Answers Mail for SQL Server sends bulk email directly from SQL Server. You could try searching for a tool that does something similar for the database you're using.
There's also a tutorial here and here on creating your own mailer.
use ActionMailer(tutorial) (docs), it comes with Rails and you should be able to rig it to run from a rake task.
There's a relatively new project called Maktoub which claims to be a Rails engine for email newsletters. I haven't tried it yet, but it looks promising.