On Thu, November 12, 2009 1:49 pm, Joseph Morgan wrote: >>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?
That wouldn't be my aim; I personally dislike 'landing' pages, but it might be a consequence :( >>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? Yes, all access including authentication on both servers is https. J. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
