Ha, sorry for the useless detail :-) >> Is that enough of a clue? >Ha ha ha, no unfortunately not: pretty much all of the authenticators >extend from AuthenticatorBase, so the only thing it tells us is that >there is at least *some* authenticator. > >If nobody else replies, I'll try to trace-through the code to figure >out what kind of authenticator you are getting. I'm guessing >NoLoginAuthenticator is the one, though.
Thanks for the offer of tracing through the code. If you're really interested, here is a starting point: https://github.com/DSpace/DSpace/tree/master/dspace-api/src/main/java/org/dspace/authenticate ________________________________________ From: Christopher Schultz [ch...@christopherschultz.net] Sent: Wednesday, September 09, 2015 3:09 PM To: Tomcat Users List Subject: Re: seeking help with stabilizing the persistence of a JSESSIONID -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hardy, On 9/9/15 3:54 PM, Pottinger, Hardy J. wrote: > Well... it occurred to me that from time to time we happen to have > stack traces show up in our log files due to some error or another, > and, I could just *look* at the log files. Sure enough, here's an > example of one line of interest (there are many similar ones): > > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticat orBase.java:503) > > Is that enough of a clue? Ha ha ha, no unfortunately not: pretty much all of the authenticators extend from AuthenticatorBase, so the only thing it tells us is that there is at least *some* authenticator. If nobody else replies, I'll try to trace-through the code to figure out what kind of authenticator you are getting. I'm guessing NoLoginAuthenticator is the one, though. - -chris > From: Pottinger, Hardy J. Sent: Wednesday, September 09, 2015 9:35 > AM To: Tomcat Users List Subject: RE: seeking help with stabilizing > the persistence of a JSESSIONID > > Hi, thanks for following up! No, no luck at all. The web > application I'm working with is based on Apache Cocoon 2.2, so, no > JSPs in sight. I am actually weighing my options, I have a choice > to either pursue making the current design work (i.e. try to get > the session to stick around long enough so I can use it), or else > change the design and go with a more conventional "pass the return > URL around as a parameter in the request" approach. I'm leaning > towards the latter, as it sidesteps this whole issue we're having > with session fixation protection, *and* it deals with a slightly > esoteric use case, where a user encounters a password challenge > when attempting to view a restricted item, backtracks, then later > chooses to log in for some other reason, and is returned to the > original restricted item page (because the redirect URL is still in > the session). > > If I do continue to persue the session route, I'll let you know if > I'm able to determine what authentication class ends up in the > stack trace. > > --Hardy ________________________________________ From: Christopher > Schultz [ch...@christopherschultz.net] Sent: Wednesday, September > 09, 2015 8:24 AM To: Tomcat Users List Subject: Re: seeking help > with stabilizing the persistence of a JSESSIONID > > Hardy, > > On 9/4/15 4:32 PM, Pottinger, Hardy J. wrote: >>> Are you using AJP or HTTP as your proxy protocol? If AJP, are >>> you using tomcatAuthentication="false" on your <Connector>? >>> I'm not exactly sure what happens when you do that... you might >>> get a NonLoginAuthenticator. > >> in our Vhost file, we have this: > >> <Location "/xmlui"> ProxyPass ajp://127.0.0.1:8009/xmlui >> retry=1 keepalive=on ProxyPassReverse >> ajp://127.0.0.1:8009/xmlui ShibUseHeaders On SetEnv >> proxy-sendchunked 1 </Location> > >> in our server.xml file, we have this: <!-- Define an AJP 1.3 >> Connector on port 8009, just on localhost --> <Connector >> port="8009" enableLookups="false" redirectPort="8080" >> protocol="AJP/1.3" address="127.0.0.1" >> tomcatAuthentication="false" maxSwallowSize="-1" >> connectionTimeout="1232000" disableUploadTimeout="false" >> connectionUploadTimeout="1232000" URIEncoding="UTF-8"/> > >> So, we're using tomcatAuthentication="false" > >> I will try your suggestion of using NonLoginAuthenticator and >> see what I get. If it doesn't work, I'll try your suggestion of >> setting a breakpoint and using a debugger to look at the stack. > > Any luck? > > You don't have to use a debugger to get a stack trace: just create > a JSP and have it 'throw Exception("getting a stack trace")'. > > -chris > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8JH1AAoJEBzwKT+lPKRYqA8QAIvtWo5jBOYQqcszAqpbfwnP ZERDPwEISLWfuqbUZbmawB1HI1GI9sMPeUZ7su/NwyOQiCgpgM4kSqR4sxTMAtEC DMiN9QSNNfs9YErX/UBsisMTfeOwmO1+ME7oU2wQtGD7dirZAM3N5NrADPqTFo9f eU94YR8TbFq+GViIUvlm2OBxGa/nHZyumcC6BGJ0EroGTG7HUlRkj9OHZJMl+WgC gCqJ+lPxTuCFI0Q/SdeG+BA2RMBBlTV8UJ26kPGIwBcd+SSCmKgmrglBqteQQZn5 Nq5SXvMpkl+E4JAGeNy9IeGZBOQ3roRxJ47jxWR5p6CS037S+hZIwPEPCsCpEQAU b68ibgYWLYJnzhmbO90MdppE6vr4dSbKp2x8Gjkt2PV9gCZZBum0SdYGqE7Gbxxp QBXTXAmeI/0QpBP9JEOuTZSV6DD6KDg3wKEfDzSL2H4LJorBAis1RhOilkMPTrzm PQWh/MCMcwkj3A+9fItq4uNPK5pfXmOFZ693oB1T9JyQtOhIW3TA7RhpHI2g3fnn jnXc/s4FNtG7pasfQc2Hxa5VXnp9VMi1cQeRCTcffxm0VEKQ0LkR9mtj/fVPTMEL xUF8ZLCLlJZ6LdlcbtCCZZpzbQpoyzKBHTYWc1b98OK0opB+W0C41Oyd0+tSpnpj 4qllAkaNMihnhwf4M3v1 =FX9P -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
