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 [email protected] [email protected] Le 24/10/2024 à 14:10, [email protected] a écrit :
I am converting over a part of an application from using the authc filter to a bearer token filter for the API and I have things working well enough, but one place I have an issue. I expose an openapi-ui in my application and if I'm authenticated to the "web" side with the authc filter and attempt to use the openapi-ui (basically swagger-ui) to test an API call it fails with unauthorized even though the bearer token is being authenticated because as far as I can tell it's pulling my "web" principal out of the ThreadContext and authorizing with that. The API keys are associated with a user in my data model but each have their own permissions as selected at creation time. The principal for an API key (which is purely permission based) is different from the principal for the authc filter (which is just RBAC at this point). If I'm already logged into the application then one of the first things that happens when I attempt to make a request using the openapi-ui is: 06:57:07,762 TRACE [org.apache.shiro.util.ThreadContext] (default task-22) Bound value of type [org.apache.shiro.web.subject.support.WebDelegatingSubject] for key [org.apache.shiro.util.ThreadContext_SUBJECT_KEY] to thread [default task-22] and then much later at the bottom I can see it logging my web principal (showing my username). but if I just use curl early on I see: 07:02:53,626 TRACE [org.apache.shiro.mgt.DefaultSecurityManager] (default task-22) No identity (PrincipalCollection) found in the context. Looking for a remembered identity. and then it flows completely through the bearer process and it works fine because it's using THAT principal and getting the proper permissions. Is there a way to prevent this from happening? I think it's just the fact that the browser is "logged in" and since it's going through the request to those pages it loads up the web user first and binds it and then the bearer token is ignored and permissions lookup doesn't work. Thanks, Dave
