migration 1.1.0 -> 2.0.0 simultaneous inbound and outbound rewriting problem

Splash Forums Rewrite Users migration 1.1.0 -> 2.0.0 simultaneous inbound and outbound rewriting problem

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

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

    kvdev
    Participant

    I am using the following approach to rewrite my application urls

    After upgrading to rewrite 2.0.0 the inbound and outbound rewriting does not work proberly.
    Outbound urls are only rewritten if a page is not called by its rewritten inbound url.
    It seems as if outbound rewriting is omitted if an inbound rule applies.

    Do I have to call event.proceed() or set the flow in order to get things to work properly?

    #23669

    kvdev
    Participant

    sry, this is the approach i used

    #23670

    kvdev
    Participant
    #23671

    Could you share a bit more of your setup. Especially some details about your Rewrite configuration as it looks today?

    #23676

    kvdev
    Participant

    this is the relevant code:

    
    //generic inbound url handling
          .addRule()
            .when(Direction.isInbound()
                  .and(Path.matches("/{locale}/{path}")))
    			.perform(PhaseAction.retrieveFrom(El.retrievalMethod("localeBean.localeCodeChanged"))
    					.and(new HttpOperation() {
    					@Override
    				public void performHttp(HttpServletRewrite event, EvaluationContext context){
    
                                            HttpInboundServletRewrite inboundEvent = (HttpInboundServletRewrite) event;
    							
    					//get path and locale
    					String path = (String) Evaluation.property("path").retrieve(event, context);
    					String locale = (String) Evaluation.property("locale").retrieve(event, context);
    							
    					String view = getView(locale, "/" + path);	
    					Forward.to(view).perform(event, context);
    				}
    				}))
    		.where("locale").matches(SUPPORTED_LOCALES_PATTERN).bindsTo(PhaseBinding.to(El.property("localeBean.localeCode")).after(PhaseId.RESTORE_VIEW))
                   	.where("path").matches(".*")
    
    //generic outbound url rewriting
    	.addRule()
    	.when(Direction.isOutbound()
    	       .and(Path.matches("/{viewId}.jsf")
    	       .andNot(Path.matches("{*}javax.faces.resource{*}"))
    	))
    	.perform(new HttpOperation() {
    			@Override
    			public void performHttp(HttpServletRewrite event, EvaluationContext context){
    	
    				HttpOutboundServletRewrite outboundEvent = (HttpOutboundServletRewrite) event;
    							
    				String viewId = (String) Evaluation.property("viewId").retrieve(event, context);
    							
    				//set locale
    				String locale = localeBean.getLocaleCode();
    							
    				//get path
    				String path = getPath(locale, "/" + viewId + ".jsf");
    							
    				DefaultParameterStore parameterStore = (DefaultParameterStore) context.get(ParameterStore.class);
    							
    				String targetURL = "/" + locale + path;
    							
    				Substitute s = Substitute.with(targetURL);
    				s.setParameterStore(parameterStore);
    				s.perform(event, context);
    			}
    	}).where("viewId").matches(".*")

    When I call the jsf page directly the outbound urls are properly rewritten on the page;
    If I call the page through its rewritten inbound url the outbound urls are not rewritten

    #23677

    And you say that outbound rules don’t work at all or not when the request is matched by an inbound rule?

    Could you test if the outbound operation is invoked? With a log statement or something like this?

    .perform(Log.message(Level.INFO, "Rewrite outbound triggered."))

    #23678

    kvdev
    Participant

    outbound rules work in general, but not when an inbound rule applies first.
    after a request is matched by an inbound rule, no outbound rewriting occurs.

    #23682

    Are you sure that no outbound rewriting occurs? Is it possible that the outbound address is actually not matching your pattern? It may be possible that you need to include the context-path (or some small difference like this):

    .when(Direction.isOutbound()
    	       .and(Path.matches(context.getContextPath() + "/{viewId}.jsf")
    	       .andNot(Path.matches("{*}javax.faces.resource{*}"))
    	))

    I would start by adding the rule:

    .addRule()
    .when(Direction.isOutbound())
    .perform(Log.message(Level.INFO, "Rewrite outbound triggered."));

    See if this triggers.

    #23683

    kvdev
    Participant

    I’ve made a very simple test case. When calling /index in the browser no outbound rewriting is triggered.
    When calling /pages/public/index.jsf outbound rewriting is triggered.

    
         .addRule()
          .when(Direction.isInbound().and(
                Path.matches("/index")
          )).perform(Forward.to("/pages/public/index.jsf"))
               			
                   			
        .addRule()
         .when(Direction.isOutbound())
         .perform(Log.message(Level.INFO, "Rewrite outbound triggered."))
    
    #23684

    What is the contents of your index.jsf file? Are there any outbound URLs?

    #23685

    kvdev
    Participant

    I have several <h:link> tags in the index.jsf.
    As I said, outbound rewriting is only triggered when calling the page directly.

    #23687

    Okay. Just making sure. As you can imagine, this would be a very severe bug if confirmed, so I am just trying to rule out the simple issues first.

    Could you attach a small sample maven project that reproduces this problem? That would help us debug it.

    Thanks! Sorry again for your trouble. We will get this fixed ASAP.

    #23688

    kvdev
    Participant

    Thanks for your fast response.
    I’ve found the issue.
    I was using a sessionId filter to disable URL-based session identifiers which was using HttpServletResponseWrapper, which was interfering in some way with rewrite. I disabled the filter and now things work as they are supposed to do.
    Thank you again for your help.

    #23689

    That would explain it. If you were overriding encodeURL() and encodeRedirectURL() and not chaining up to super.encodeURL(), etc, that would certainly explain the behavior you were seeing.

    Glad you figured it out 🙂

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

You must be logged in to reply to this topic.

Comments are closed.