>Correct, at the moment there is no requirement to actually authenticate >the user. However, I've been told to ensure that, if the client wishes >(and pays) that the solution could be expanded to do so.
I may have missed something, but are you simply trying to ensure secondary requests to web pages/resources/objects/whatever came through a singular entry point? That is, someone comes in to your web world but needs to visit Page A before requesting other pages/resources on the site? >Is this something like you are thinking; > >If the user has a session; > let them access what they want >else if the requested url has a param/value of [insert hash algor] > set the user up with a session and let them access what they want >else > return Access Forbidden >Is this possible in a filter? (My knowledge of them is currently 0; I'll >read up on them in depth tomorrow) There is no security in this approach, even if you do authenticate the user up front (as guest or otherwise), unless this token is flying around across a secured protocol. A man in the middle can intercept the token and start issuing requests as the original user. The answer is, yes, a filter can be made to ensure the token is there and reject if not, but will the initial request (the one that issues the token) and subsequent requests be exchanged via SSL?
