Brian/Lenny,
- I have a line with a url pattern that requires authcBearer and
noSessionCreation and permission
- I have a line with a url pattern that requires authc and role
1 Deploy the application and visit the openapi-ui (noSessionCreation,
anon (though I would like to have this be user instead of anon)) and
test a request against API, it works.
I can see in the shiro trace logging the principal is an API one
2 Now try to visit a protected URL that is protected by the authc filter
(which should direct to login, I login, then it redirects back to
originally requested page) and I just get a straight 401, no redirect to
login. In the logs I see:
08:19:03,894 TRACE [org.apache.shiro.realm.AuthorizingRealm] (default
task-55) Retrieving AuthorizationInfo for principals [<API-PRINCIPAL>],
I see that 3 times, I'm assuming once per realm. I don't understand how
it's even getting the API principal because the authc filter for this
url doesn't have any knowledge of the API tokens/principals, it only
handles username/password tokens.
Vice versa....
1 deploy application and visit authc protected web url: as expected,
browser is redirected to login page, I log in then I am redirected to
original page and I'm fine
2 visit openapi-ui and test a request and that api request gets 401 and
in the logs I see:
Retrieving AuthorizationInfo for principals [<username>] 3 times even
though that url is using the authcBearer filter and the request has the
appropriate Authorization header.
3 log out of the web side and retry 2, it works fine.
I understand why I'm getting 401 because the API principal does not have
the required role for authc filter and the regular user does not have
the required API permissions.
I don't understand why the subject/principal is getting "stuck" in
between requests from the same browser to different URLs. (Or is this my
fundamental misunderstanding of how the browser works?)
I turned off the cache manager and I tested FirstSuccessful instead of
AtLeastOnce authentication strategy and it doesn't seem to affect.
One thing that may be an issue is the browser continuing to send a
cookie even though it's no longer valid but I don't immediately see how
the bearer filter would make use of that.
On 10/28/2024 1:06 PM, [email protected] wrote:
I’m not sure I understand this issue.
Your different filters can (should) have different paths.
Doesn’t that work correctly? Or am I missing something significant here.
On Oct 28, 2024, at 8:54 AM, Brian Demers <[email protected]> wrote:
Consider changing the order of your filters if you want the access
token to take precedence.
On Sun, Oct 27, 2024 at 2:35 PM <[email protected]> wrote:
Yes, if I use a private browser window it works with the
openapi-ui, but then much like the other way around, the browser
is "poisoned" and if I attempt to go to the rest of the web
application I just get a 401 and it never sends me to the login
page because it's going through the token flow. I guess in a way
this is Firefox's fault, but this doesn't seem like that crazy of
a scenario for an application. I assume I'm doing something
stupid :)
We have 3 realms, one is form based, one is certificate based and
now one is token based. Is there a way that I've missed to limit
certain URLs in the shiro.ini to certain realms?
On 10/24/2024 2:51 PM, Francois Papon wrote:
Hi,
May be it's related to cookie or cache. Did you try to use the openapi-ui
with an private or incognito browser tab?
regards,
François
