After some strong advice in here some time ago I finally got around to implementing
form based container security using a jdbc realm with Glassfish and I'm pretty satisfied
with the result, it didn't really take that long to do and works fine. I was a bit confused
about exactly which digest algorithms are supported but got it working with SHA-1.
One thing I noticed is that at the EJB layer SessionContext.getCallerPrincipal() returns
ANONYMOUS when you're not logged in so I put a block on anyone registering with that
username just to avoid any confusion.
To my intended point though, prior to this change I used to automatically log the user
in following a successful registration, but this of course no longer happens. In fact for
testing purposes it would be useful to skip the login page whilst not mucking about too
much with the security infrastructure.
Does anyone know how to do this (auto-login after registration), is it another of those
things that are not recommended?
It's not recommended. Although you can probably do it without too much trouble in JEE 5, it was a royal pain in J2EE, since there was no trivial way to induce logins internally.
The main reason why you shouldn't login, though, is psychological.
By forcing a login immediately after registration, it gives the user a chance to try out the userid/password immediately. That helps catch problems where they thought one thing and typed another while they're still mentally in "registration mode". Meaning that they're most familiar with the account management details and the processes that work with them. Thus, you confirm that their account can be logged in later when they come back with more serious business in mind.
The other benefit is that the repetition of entry of credentials helps burn them into the user's teeny little brains. So they'll be more likely to remember them later. As opposed to having to call the help desk.
An IDE is no substitute for an Intelligent Developer.
Joined: May 12, 2009
Thanks Tim. On my "to do" list is functionality to ensure that the user's e-mail address is
correct. I was thinking of option a) enter this random number - send e-mail to user, or b)
captcha (PrimeFaces has a component for this).
The problem with a) is that sometimes the e-mail takes a long time to get through, it
shouldn't, but I've spent hours with a browser window open typing in a magic number and
no e-mail is ever received, presumably the thread/process doing this work on the server
With b) I'm personally finding it increasingly difficult to read these damned things. When I
tried to register with the PrimeFaces forum (which, incidentally doesn't use the PrimeFaces
captcha component) it took me two weeks to get registered. I absolutely couldn't read the
damned thing. I suspect that there's an audio variation but I was too slow to cotton on.
So, what I'm planning is that during or subsequent to registration, the user has to verify
their e-mail address by entering a randomly generated magic number. This will activate the
account and unless this is done there're only unsecured pages available (information display
etc...). I'm going to use the timer service to run the e-mail sending thread and put in place
decent monitoring to ensure that it stays alive (and keep it simple).
Brendan, I agree wholeheartedly. On the "captcha" front, the arms race between captcha renderers and reading robots has deteriorated to the point where the other day I had to try 5 different captchas before I got one that I could read well enough to have a chance of typing it directly.
Captchas ARE good for slowing down the registrar robots, but nothing stops persistent slime. The response email also helps, both in making it that much more complicated for mindless processes to obtain credentials fraudulently and to ensure that the legitimate users didn't fat-finger their email addresses. The double-entry tactic doesn't really help that much. I simply copy/paste the same address twice.
Email is not a "push" technology and it was never intended to have a guaranteed delivery time. In fact, in the original days of the Internet, it was quite possible for email to sit in a server's queue until the wee hours of the morning when a lower-cost dialup connection could be made to the next hop in the chain. We don't see too much of that anymore, but my own mail clients only poll for new mail about every 15 minutes so as to keep the load down.
Joined: May 12, 2009
Paper tape cuts between the thumb and forefinger. Disk drives the size and appearance
of top-loading clothes washing machines. sendmail.cf. The Arpanet. The first time someone
in the labs found Netscape.