[MAGNOLIA-8799] RegexpVirtualUriMapping not working as expected when start with ^ Created: 01/Mar/23  Updated: 10/Oct/23  Resolved: 10/Oct/23

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: Carlos Cantalapiedra Assignee: Oanh Thai Hoang
Resolution: Not an issue Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: 5.5h
Original Estimate: Not Specified

Attachments: Java Source File RegexpVirtualUriMappingTest.java     XML File config.modules.multisite.config.sites.mySite.xml     XML File config.modules.multisite.config.sites.travel.xml     PNG File debug.png     Zip Archive first-module.zip     File website.mySite.yaml    
Issue Links:
Problem/Incident
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Epic Link: Support
Team: DeveloperX

 Description   

Steps to reproduce

  1. Start a Magnolia instance and import the attached light module (first-module) which has a virtualUriMapping configuration
  2. Go to Site app and import the attached file config.modules.multisite.config.sites.mySite.xml
  3. Go to Pages-app and import the attached file website.mySite.yaml
  4. Navigate to http://localhost:8080/magnoliaAuthor/mySite/allowed/page1 and check that the page is shown as expected, 200 result and no 301 redirect
  5. Navigate to http://localhost:8080/magnoliaAuthor/mySite/forbidden/page1 and check that the page is shown as expected, 200 result and no 301 redirect

Expected results

/mySite/forbidden/page1 doesn't match the pattern so no redirect
/mySite/allowed/page1 does match the pattern so it goes through 301 redirect (permanent)

Actual results

/mySite/allowed/page1 doesn't match the pattern so its server as 200

Workaround

N/A

Development notes

Check the debug attachment



 Comments   
Comment by Oanh Thai Hoang [ 13/Jul/23 ]

Sorry for late reply due to my long holiday. ccantalapiedra 

 

Here is output of discovery: RegexpVirtualUriMapping did work as expectation

From https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html. ^ is used for the beginning of a line. So in your below config 

 

fromUri: /^(?!.*forbidden)(.*)

should be change to 

 

fromUri: ^(?!.*forbidden)(.*)

 

 

 

 

Here is sample unit test to show your output after changing pattern

 

@Test
public void testMAGNOLIA8799() throws Exception {
// GIVEN
RegexpVirtualUriMapping mapping = new RegexpVirtualUriMapping();
// mapping.setFromUri("/^(?!.*forbidden)(.*)"); // Not working
mapping.setFromUri("^(?!.*forbidden)(.*)"); // Working
mapping.setToUri("permanent:$1");

// WHEN-THEN for url contain forbidden
assertFalse(Pattern.compile(mapping.getFromUri()).matcher("/mysite/forbidden/page1").find());
assertFalse(Pattern.compile(mapping.getFromUri()).matcher("/forbidden/page1").find());
assertFalse(Pattern.compile(mapping.getFromUri()).matcher("forbidden/page1").find());
assertFalse(mapping.mapUri(URI.create("/mySite/forbidden/page1")).isPresent());


// WHEN-THEN for url does not contain forbidden
assertTrue(Pattern.compile(mapping.getFromUri()).matcher("/allowed/page1").find());
assertTrue(Pattern.compile(mapping.getFromUri()).matcher("/mysite/allowed/page1").find());
Optional<Result> optUri = mapping.mapUri(URI.create("/mySite/allowed/page1"));
assertTrue(optUri.isPresent());
assertEquals("permanent:/mySite/allowed/page1", optUri.get().getToUri());
}

 

or you can find my attached unit test class: RegexpVirtualUriMappingTest.java

Comment by Georgia Baker [ 01/Aug/23 ]

Flag added

Waiting for feedback from support

Comment by Oanh Thai Hoang [ 08/Sep/23 ]

Hi ccantalapiedra , is there any thing update?. Mean while I will move this ticket to Not ready. Thank you

Generated at Mon Feb 12 04:35:54 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.