Default "deny"

Splash Forums Rewrite Users Default "deny"

This topic contains 13 replies, has 3 voices, and was last updated by  Lincoln Baxter III 5 years, 2 months ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #18545

    pavel.arnost
    Participant

    Hi,

    I would like to have a valid “sitemap” at the beginning and default “deny” rule at the bottom of ConfigurationBuilder chain, something like:

    ConfigurationBuilder.begin()
    .addRule(Join.path("/").to("/index.html"))
    .addRule(Join.path("/login").to("/login.html"))
    .addRule(Join.path("/registration").to("/registration.html"))
    .addRule(Join.path("/myProfile").to("/myProfile.html"))
    .defineRule()
    .when(Direction.isInbound().and(DispatchType.isRequest()))
    .perform(Redirect.temporary("/"))

    I see something similar at https://github.com/ocpsoft/rewrite/blob/master/showcase/access-control/src/main/java/org/ocpsoft/rewrite/showcase/access/AccessRewriteConfiguration.java, but in my case, last rule always wins.

    Thanks,

    Regards

    Pavel

    #22786

    Could you try to add .perform(Lifecycle.handled()) to the Join rules? So that the all look like this:

    .addRule(Join.path("/login").to("/login.html").perform(Lifecycle.handled()))

    I think with this code the first match should suppress further rules from matching. Could you try it?

    #22787

    pavel.arnost
    Participant

    Hi,

    I tried:

    ConfigurationBuilder.begin()

    .addRule(Join.path(“/”).to(“/index.html”).perform(Lifecycle.handled()))

    .addRule(Join.path(“/login”).to(“/login.html”).perform(Lifecycle.handled()))

    .addRule(Join.path(“/registration”).to(“/registration.html”).perform(Lifecycle.handled()))

    .addRule(Join.path(“/myProfile”).to(“/myProfile.html”).perform(Lifecycle.handled()))

    .defineRule()

    .when(Direction.isInbound().and(DispatchType.isRequest()))

    .perform(Redirect.temporary(“/”))

    but it’s the same.

    #22789

    Hi, which version of Rewrite are you using? Would you mind trying 1.0.6-SNAPSHOT? I think this should work. If it still does not, do you think you could upload a small application or Arquillian test case that reproduces this issue? It would help us debug. Thanks!

    #22790

    pavel.arnost
    Participant

    Hi Lincoln,

    I tried 1.0.6-SNAPSHOT and it behaves differently, but it also doesn’t work. I attached simple project. Excerpt from ConfigurationProvider:

    ConfigurationBuilder
    .begin()
    .addRule(Join.path("/index").to("/index.html")) // returns 403
    .addRule(Join.path("/test").to("/test.html").perform(Lifecycle.handled())) // returns 404
    .defineRule()
    .when(Direction.isInbound().and(DispatchType.isRequest()))
    .perform(Response.setCode(403));

    And is it possible to do things like this?

    HttpOperation loginRequiredCheck = new HttpOperation() {
    public void performHttp(HttpServletRewrite event, EvaluationContext context) {
    if (event instanceof HttpInboundServletRewrite) {
    if (!userIsLoggedIn) {
    // record current url in session and forward user to login page
    } else {
    // do forward as instructed in Join
    }
    }
    }
    };

    ConfigurationBuilder
    .begin()
    .addRule(Join.path("/test").to("/test.html").perform(loginRequiredCheck)
    ...

    Thanks,

    Regards

    Pavel

    #22791

    Thanks for attaching the test case. I debugged it and I think I found the root cause of your problems.

    In evaluate() the join class adds the operation as a pre-operation to the evaluation context. So Lifecycle.handled() will be executed before the perform() operation of the rule gets called which means that perform() won’t be executed at all. Therefore you get a 404.

    @lincoln: Wouldn’t it make sense to let Join always call Lifecycle.handled()? I don’t think it makes sense that other rules can also match after a join. Perhaps we could call Lifecycle.handled() by default and let users override this behavior using something like this:

    .addRule(Join.path("/index").to("/index.html").notExclusive())

    #22792

    Hmmm.. Seems I was wrong… Join performs a forward. And a forward flow is also treated as a “handled” flow. But I don’t understand why the last rules get the chance to send the 403….

    Investigating…

    #22793

    I got it.

    The problem was that the fallback rule was evaluated before the joins where executed. I don’t understand why this happens, but adding a priority to the fallback rule which is higher than the default priority of your configuration provider fixes the problem:

    public class TestHttpConfigurationProvider extends HttpConfigurationProvider
    {

    @Override
    public Configuration getConfiguration(ServletContext context)
    {
    return ConfigurationBuilder
    .begin()
    .addRule(Join.path("/index").to("/index.html"))
    .addRule(Join.path("/test").to("/test.html"))
    .defineRule()
    .withPriority(20)
    .when(Direction.isInbound().and(DispatchType.isRequest()))
    .perform(Response.setCode(403).and(Lifecycle.abort()))
    ;

    }

    @Override
    public int priority()
    {
    return 10;
    }
    }

    Please also not the Lifecycle.abort() that I had to add so that the lifecycle is correctly aborted here.

    #22794

    Hmmmm… I’ll take a look at this, but I think that this is possibly because Join is a pre-built rule and probably comes with a default priority? It’s also possible that RuleBuilder is setting some kind of priority which is throwing things off. We will fix it :) I should have time when I wake up to take a look.

    #22795

    Ok, I found the issue – https://github.com/ocpsoft/rewrite/commit/dd76f0276a3301a8ebe4d5c7c69a687cd01ab729

    Pretty simple fix :) also added a new test case for this so it will not be broken in the future.

    Please try the latest 1.0.6-SNAPSHOT and let us know if you have better luck :)

    Thanks,

    Lincoln

    #22796

    pavel.arnost
    Participant

    Hi,

    thanks. Where can I find recent builds? I found only http://ocpsoft.org/repository/org/ocpsoft/rewrite/rewrite-servlet/, but these builds are quite old.

    Thanks,

    Regards

    Pavel

    #22797
    #22798

    pavel.arnost
    Participant

    I tried 1.1.0.Final and it works, of course :-) Thanks again.

    #22799

    Excellent! Thanks for letting us know it’s fixed :)

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.

Comments are closed.