Re: Shiro: possible to configure part of the unauthenticated URLs to return 401 instead 302?
Question: when I do this: > [main] > authc = org.apache.shiro.web.filter.authc.PassThruAuthenticationFilter [snip!] > [urls] > /api/** = anon > /** = authc, role[myapprole] don't I then use a different filter than PassThruAuthenticationFilter for /api/? Can I do this and still use @RequiredPermission() and @RequiredRole() on the resources? Or will the necessary cookie and headers not be present?
Re: Shiro: possible to configure part of the unauthenticated URLs to return 401 instead 302?
> Brian Demers :
> You can also use `@RequireRoles("myapprole")` annotation instead of
> the permission one.
> I think the problem you might be running into is the
> `PassThruAuthenticationFilter` doesn't have a "permissive" option, so
> it's likely redirecting on that fitler.
Ok. I can't remember why I'm using that one, but it is the one that had
the behaviour I desired once upon a time... ah! The comment says why:
// Using the PassThruAuthenticationFilter instead of the default authc
FormAuthenticationFilter
// to be able to do a redirect back "out of" authservice to the originalUrl
It's because of my usage of shiro to something other than authentication
inside of a java webapp. I use it to provide cookie authentication to
nginx and across multiple web applications.
> To work around this, you could use the form auth filter, or create
> your own filter that instead of redirecting returns a 401
> https://github.com/apache/shiro/blob/0c0d9da2d81a4b24de6e02bc1c8a2ad1b5ef32d7/web/src/main/java/org/apache/shiro/web/filter/authc/PassThruAuthenticationFilter.java#L49-L56
> Bind your new fitler to `/api/**`
> Does that help?
Yes, I think so, thanks!
But it will require some thought and experimentation...
But since I won't do redirects on the /api/* paths, there is no need for
the PassThruAuthentication behaviour here, so I could use the regular
authc filter for this path.
Re: Shiro: possible to configure part of the unauthenticated URLs to return 401 instead 302?
You can also use `@RequireRoles("myapprole")` annotation instead of
the permission one.
I think the problem you might be running into is the
`PassThruAuthenticationFilter` doesn't have a "permissive" option, so
it's likely redirecting on that fitler.
To work around this, you could use the form auth filter, or create
your own filter that instead of redirecting returns a 401
https://github.com/apache/shiro/blob/0c0d9da2d81a4b24de6e02bc1c8a2ad1b5ef32d7/web/src/main/java/org/apache/shiro/web/filter/authc/PassThruAuthenticationFilter.java#L49-L56
Bind your new fitler to `/api/**`
Does that help?
On Tue, Dec 7, 2021 at 2:14 PM Steinar Bang wrote:
>
> Side note: shiro-jaxrs and RequiresPermissions annotations may be a way
> to accomplish what I want to do.
>
> But what I really wanted was something simpler: avoid 302 redirects for
> the part of URL space used by ajax calls (since 302s are handled by the
> browser and never reach the ajax code waiting for a response).
>
> I'm completely OK with having access to the endpoint managed by the
> shiro filter. Returning 401 until the frontend logs a user in is
> completely OK. I don't need the fine grained permission control offered
> by shiro-jaxrs and @RequirePermissions. I just want to avoid 302 on the
> REST operations.
>
> Should I add a shiro feature request for this? (I imagine I'm not the
> only one wanting something
2021 December Board Report Draft
The 2021 December ASF board report is due tomorrow. I've created an initial draft here: https://svn.apache.org/repos/asf/shiro/board/2021-12.txt Comments, suggestions, and feedback are welcome. Otherwise, it will be submitted tomorrow. Thanks to Benjamin (bmarwell) for putting this together! Thanks, -Brian
Re: Shiro: possible to configure part of the unauthenticated URLs to return 401 instead 302?
Side note: shiro-jaxrs and RequiresPermissions annotations may be a way to accomplish what I want to do. But what I really wanted was something simpler: avoid 302 redirects for the part of URL space used by ajax calls (since 302s are handled by the browser and never reach the ajax code waiting for a response). I'm completely OK with having access to the endpoint managed by the shiro filter. Returning 401 until the frontend logs a user in is completely OK. I don't need the fine grained permission control offered by shiro-jaxrs and @RequirePermissions. I just want to avoid 302 on the REST operations. Should I add a shiro feature request for this? (I imagine I'm not the only one wanting something
Re: Shiro: possible to configure part of the unauthenticated URLs to return 401 instead 302?
> Brian Demers : > This post is a little old (dependency wise), but it should still be accurate. Hm... I'm on shiro-1.7.0 currently, so the mentioned shiro-jaxrs should be available...? (and currently on jersey 1.8.4, if that matters...?) > See the bit about the "permissive" filter. > https://stormpath.com/blog/protecting-jax-rs-resources-rbac-apache-shiro Interesting! > If you go this route, you will need to ensure you are checking access > another way: annotation, another filter, etc. Ie. the idea is to let everything to the API through untouched and then use annotations to set permissions on the jersey resources, and then let shiro-jax handle access control? Is it possible to split the handling? I.e. to use regular handling on the frontend and shiro-jaxrs and annotations on the REST API? Will something like this work as expected? [main] authc = org.apache.shiro.web.filter.authc.PassThruAuthenticationFilter shiro.loginUrl = /login shiro.unauthorizedUrl = /unauthorized [urls] /api/** = anon /** = authc, role[myapprole] "work as expected" means: 1. /** will be handled with redirect to /login when not logged in 2. /api/** will pass through, but shiro-jaxrs handling will work Or will shiro-jaxrs be affected by the shiro.ini config and let everything though, whatever the @RequiresPermission() says? Thanks! - Steinar
