> Brian Demers :
> That should work, keep us posted!
Ok, 2 years, 8 weeks, and 5 days has passed, but now I finally got
around to it, and I can report it worked perfectly:
1. User with the required role is logged in: a POST to the API gets 200 OK
2. User withot the required role is logged
That should work, keep us posted!
On Wed, Dec 8, 2021 at 11:37 AM Steinar Bang wrote:
>
> > Brian Demers :
>
> > Cookies will get processed, but if you are using some other form of
> > header based auth they wouldn't be (unless you a corresponding filter
> > configured)
>
> In this case I'm
> Brian Demers :
> Cookies will get processed, but if you are using some other form of
> header based auth they wouldn't be (unless you a corresponding filter
> configured)
In this case I'm thinking of what's set by the
PassThruAuthenticationFilter when authenticating the frontend.
Will
Cookies will get processed, but if you are using some other form of
header based auth they wouldn't be (unless you a corresponding filter
configured)
On Tue, Dec 7, 2021 at 5:04 PM Steinar Bang wrote:
>
> Question:
>
> when I do this:
>
> > [main]
> > authc =
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
> 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
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
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
> 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.
>
This post is a little old (dependency wise), but it should still be accurate.
See the bit about the "permissive" filter.
https://stormpath.com/blog/protecting-jax-rs-resources-rbac-apache-shiro
If you go this route, you will need to ensure you are checking access
another way: annotation, another
Is it possible to configure a part of the URL space to return 401
instead of 302 when unauthenticated?
I would like to avoid 302 redirects for calls to the REST API.
Thanks!
- Steinar
11 matches
Mail list logo
