Tag Archives: development

State of Authentication

I’ve been working on some new websites the past month or so, and one thing that has me second-guessing myself and generally wasting a bunch of time is authentication. Ever since I read Jeff Atwood’s post¬†on this issue, I’ve been trying to figure out the ideal authentication setup for websites. Currently, I see 4 options:

Classic username/password

Pros:

  • Fairly straightforward to implement.
  • Everyone is used to it.

Cons:

  • A fair amount of work (ie, a signup page, login page, reset password page, session handling, etc)
  • Forces your users to remember (or more likely, re-use) a password.
  • You put your users at risk if you don’t use good practices to manage passwords.
  • Since most users re-use login info across multiple sites, if they get compromised on one of those sites, and unauthorized user can access their account on your site and cause problems.

Facebook Authentication

Pros:

  • Easy to implement.
  • Easier for your users to gain access to your website.
  • A very large percentage of the internet has a Facebook account.
  • No risk of compromising your users.

Cons:

  • Not everyone has a Facebook account.
  • Those who do might not want to associate it with sites they use.
  • Frighteningly large numbers of Facebook accounts are compromised daily, meaning you can still face unauthorized use of your site.

Basic OpenID

Pros:

  • Doesn’t require your users to signup on your site.
  • Doesn’t compromise users if your database is compromised.

Cons:

  • Slightly more difficult to implement.
  • Can be unfriendly to non-technical users.

JanRain Engage (or similar service)

Pros:

  • Very easy to implement (I’ve implemented JanRain in half a dozen languages/platforms now, and it is incredibly easy).
  • Gives your users lots of options (ie, if you offer Google, Facebook, Twitter, Yahoo, LinkedIn, and Windows Live as options, chances are pretty high that any given user is going to use at least one of those).
  • Doesn’t compromise your users if your database is compromised.
  • No requirement for a user to signup on your site, but you can still get a lot of useful data in some cases (although relying on it probably isn’t a good idea).

Cons:

  • Expensive if you create a lot of sites with low revenue per user (JanRain starts at $10/month).
  • Giving your users a lot of options is nice, but for those who have accounts with a lot of the options you provide, it can be tricky to remember which one you used to signup for which sites.
  • Relying on a third-party for authentication can make your website unusable if there is a technical outage, they terminate their relationship with you, or they go out of business. There are ways to mitigate the last two, but they require a lot of work.

Conclusion

I’m still not sure of the best option when it comes to authentication. It is clear to me that requiring a unique (or pseudo-unique, since users tend to use the same login info for every site) login for each site on the internet is a broken paradigm, but the other solutions have drawbacks of their own. I used JanRain on my last 2 sites, and am generally very happy with it, but I am still fairly uneasy about relying on a third-party service to handle such a critical part of my websites.

JDK 6 update 21 kind of breaks Eclipse on Windows

If you recently upgraded to JDK 6 update 21 on Windows and are noticing lots of Eclipse problems, I probably know why (and can show you how to fix it).

First, some background. The HotSpot VM (Sun’s implementation) has a concept known as the Permanent Generation, or PermGen for short. Its main purpose is to confound users and it is rumored to be going away in future releases of HotSpot. By default, the VM allocates 64 MB for the PermGen space, which is often enough. However, Eclipse installations with a lot of plugins tend to need a lot more.

Because Eclipse is meant to work on multiple JVMs, the stock eclipse.ini doesn’t directly set the PermGen size, it has a line that looks like this:

–launcher.XXMaxPermSize
256m

That will tell the Eclipse launcher to set the perm size, if it is running on the HotSpot VM. Unfortunately, it appears this quit working with update 21 – a quick check with VisualVM showed that this flag wasn’t working and no matter what you set it to, your VM would have only 64MB of PermGen space.

It appears that the cause of this is that with update 21, the vendor flag was changed to Oracle, which broke Eclipse’s VM detection code. Thus, the flag is never being passed through to the VM. It appears as though this only happens on Windows and only when running the Sun (sorry, I’ll never call it Oracle) JVM.

Fortunately, it is easy to fix. Simply add this flag to the -vmargs section of your eclipse.ini (it should be at or near the bottom):

-XX:MaxPermSize=256M

That will directly set the PermGen size and should fix any PermGen errors you were running into.

Who knows what else changing the vendor flag broke?