Hi Mark, everyone-

I've constructed a sample app of ~5 files.  The code is bundled in the jar
file in the WEB-INF/lib directory.  Here's a public url for the application
(test.war; 8K):


https://drive.google.com/file/d/1mZRXrm90F4WN3mizqoqrWYmQ1HHfrSS4/view?usp=sharing

To reproduce the problem in tomcat 8.5.24 (for me):

 1)  make a user available with the role "testrole" (I just user
tomcat-users)

 2) startup tomcat, copy the war file into webapps

 3) go to the application homepage, index.jsp should auto load

 4) enter username and password and login; it should change to the username
you're authenticated with

 5) hit the auth test link and it should give you a success message

 6) hit the same link again and it should give you a 403

If you want to see how things are changing, I created an unprotected page
called /authinfo (no jsp) that shows the logged in user and role.  Here's
what it shows as you proceed through the test:

 * no user or role
 * user and role
 * user, but no role

If you do this same process in tomcat 8 (8.0.43, for me) it works fine,
particularly, the you can hit the link as many times as you want and the
roles never go away until you logout.  And generally, the login/test/logout
works perfectly, where in 8.5 even if you logout it doesn't always log you
back in the next time either.  Sometimes its takes several attempts.

Hopefully this is enough to give me some guidance.  Some more info, if it
helps:

 * macOS 10.13
 * jdk1.8.0_131

Please let me know if you have any questions.  Thanks again for the help!

Robert

(Note: I ripped this code from a larger codebase, so please don't hold me
to the strictest coding standards :) )



On Fri, Jan 19, 2018 at 12:37 AM, Robert J. Carr <rjc...@gmail.com> wrote:
>
> OK, thanks Mark, I'll try to come up with a test plan, but I'm seriously
pressed for time as this has eaten two full days.  Thanks again for the
help!
>
> On Fri, Jan 19, 2018 at 12:14 AM, Mark Thomas <ma...@apache.org> wrote:
>>
>> On 18/01/18 22:03, Robert J. Carr wrote:
>> > (Bear with me as there are a lot of details; I'll try to be as clear as
>> > possible)
>> >
>> > I've been setting up a simple application in tomcat 8.0 where some
>> > resources are protected but others aren't.  I want to login using AJAX
>> > instead of FORM or BASIC so I don't have any login-config specified in
my
>> > deployment descriptor (nor any security-roles defined).
>> >
>> > For testing, I have a custom form that sends login info asynchronously
to
>> > an unprotected login service which calls login().  On the same page as
the
>> > login form, I have a test button that makes an asynchronous request to
a
>> > protected resource (using a @ServletSecurity annotation).  As expected,
>> > before calling login (and thus login()) I get a 403, but after doing
the
>> > login() I get a 200 and can see the response text.  This all works
fine in
>> > tomcat 8.0.
>> >
>> > However, when I try the application in tomcat 8.5, with the same
server and
>> > application config, something different happens.  I do the login and
call
>> > the protected resource and get the 200 as before, but now every
subsequent
>> > call to the protected resource returns a 403.  I thought maybe there
was
>> > something peculiar about this specific protected resource, but not the
>> > case, any protected resource works the first time, but not subsequent
times.
>> >
>> > To confirm what is going on, I created an unprotected resource that
>> > provides auth info, and I can see after I login() it reports my
username
>> > and my affiliated roles (using isUserInRole() for known role names).
And I
>> > can refresh this info any number of times and it doesn't change.  But
as
>> > soon as I access a protected resource, twice, the unprotected auth info
>> > still shows my username, but now my roles are stripped.
>> >
>> > Thinking there is something wrong with login(), I change to using
BASIC and
>> > run similar tests, never using the login() call, and everything works
fine;
>> > notably, I can access a protected resource more than once.
>> >
>> > Strangely, what I also unexpectedly noticed is now that I have BASIC
>> > specified, when I do use login() things are working fine now even if I
>> > never get a BASIC prompt.  So, I can access a protected resource more
than
>> > once.
>> >
>> > I know this sounds like a weird state issue, but I've restarted web
>> > servers, browsers, deployed, undeployed, and redeployed apps dozens and
>> > dozens of time.  And I even confirmed the 200 and subsequent 403 calls
were
>> > exactly the same; notably, both had the same session cookie
information.
>> >
>> > So, if this isn't a tomcat bug, which of course I'm very hesitant to
imply,
>> > then maybe there is something that changed in the configuration that
was
>> > optional before but maybe isn't now?  Maybe I have to specify BASIC or
FORM
>> > even if I never plan to use it?  Any other suggestions?
>>
>> Create the simplest possible test case that demonstrates this so folks
>> can investigate? There are enough moving parts that trying to reproduce
>> this solely from your description is likely to miss something.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>

Reply via email to