I read this post and have a question...and maybe I'm not understanding https correctly, but why is your login PAGE secure? I wouldn't care if someone sees an empty page with a prompt for the username and password. The post should be secure though... In other words... can't you have a page http://www.example.com/login.jsp post to something like https://www.example.com/login.do (this would be the url in the form tag) with the actual login action being secure? My understanding is that on the post, a secure session will be established and THEN the username and password will be posted. Then users would bookmark the log-in page as a non-secure page, and still be able to login without any funky work-around.
If this understanding is correct, then if someone bookmars a secure page, they should get redirected to the login page anyway since they need to login first. Thanks, Kevin Williams On Mon, 2003-11-17 at 08:15, Andrew Mottaz wrote: > > On 11/17/2003 06:32 AM Andrew Mottaz wrote: > >>> http://nagoya.apache.org/bugzilla. However, there aren't very many > >>> developers who like the idea of allowing you to hang yourself :). > >>> > >> Thanks much for the tip -- I have to disagree about this not being a > >> necessary change. There are plenty of apps where people browse without > >> a secure connection, but have to log in to perform some functions. > >> Users like to bookmark pages -- why should I force them to bookmark only > >> non-secure pages? Giving a developer control over how session cookies > >> function is better than forcing a hack where you have to always redirect > >> to a non-secure page to establish the session. If you are writing an > >> application where the session data is so sensitive that you have to > >> protect against session hijacking, you should know about the difference > >> between secure and non-secure cookies. I've got no problem if the > >> default behavior uses secure cookies when ever possible, but change the > >> "Session uses cookie" parameter to have a flag that allows session > >> cookies to always be non-secure. > > > > Andrew, > > what reason is there for preventing users from bookmarking secure pages? > > I don't follow you there. > > > > Also, as far as I can see, the java community has decided that once you > > start a secure session, you should stay in a secure session, for various > > security reasons. Are you doing a secure login and then redirecting back > > to http afterwards? > > > > Adam > > > Hi Adam, > > If a user bookmarks a secure page, and then tries to browse a non-secure > page, the session is lost. > > The decision to keep a session secure iff the FIRST access is secure does > not make sense to me. > > Imagine the following scenario -- A web site has different levels of user > access. The difference between the users is what products they can see. > The data is not terribly sensitive. However, the log-in should be secure > for several reasons -- 1) For the users perception -- people do not like the > "This form is not secure" message when logging in. 2) Capturing a user id > and password is worse than hijacking one session. > > Now -- I have a web site with hundreds of pages of product data, and > thousands of users. Many of these users bookmark the page > https://www.example.com/jsp/login.jsp > > So -- if I want to allow users to bookmark this page, they will create a > secure session. When they then browse the pages, I have two options: > > 1) Keep all of the links secure > > 2) Redirect them to a non-secure page (To establish a non-secure session), > and then send them back to the secure log-in page. > > > Option 1 is unacceptable -- the overhead of having all of these connections > encrypted is not a viable option. > > Option 2 is a hacky workaround -- cookies have a Secure=yes flag so that it > can be set and un-set as appropriate. > > > Also -- this is the standard for Tomcat -- not Java --( it may be in the > servlet/jsp spec -- but if so, it is a new addition). Other Java based app > servers treat this differently. > > Finally -- I know that ASP used to have the OPPOSITE implementation -- > session cookies were always non-secure. This is worse than Tomcat, but both > are wrong. The developer needs to make the decision about what is > appropriate. > > > > Again -- Just my 2 cents -- Is there a security issue I'm missing? If the > argument is that you should NEVER go from secure to non-secure, the Tomcat > solution does not assure that. It only means that you have to go non-secure, > secure, and then non-secure. That seems quite arbitrary to me. > > > Thanks, > > Andrew > > > -- > Andrew Mottaz > Site 9 :: Internet Business Solutions > 116 W. Illinois, Ste 6E > Chicago, Illinois 60610 > 312.670.8469 > www.site9.net > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
