[MAGNOLIA-245] Failing second access to secured page on public instance Created: 14/Dec/04  Updated: 23/Jan/13  Resolved: 17/Dec/04

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 2.0 Final
Fix Version/s: 2.0.3

Type: Bug Priority: Major
Reporter: Mirko Brandner Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP


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:

 Description   

Hallo,

I think I found a new bug with a failing second access to a secured page on public instance.

What I did:
1) first, I created a deny for a page (let's call it ONE) in author and activated it
2) second, I created a user and a password and activated this user
3) to be sure, I restarted public
4) with a fresh browser instance (all cookies and offline stuff deleted) I surfed to that secured page ONE, the enforced login shows up
5) I entered the newly created user and the password so the page ONE was successfully shown
6) I chose a different page from the navigation
7) I navigated back to the page ONE but the default page as configured by ResourceNotAvailableURIMapping only was shown

THE EFFECT: from then on, no second access to the secured page is possible. Except for public's restart.

MY WORKAROUND as proposed by Ralf Hirning:

  • Turn off caching for the secured page

Wonder what you guys will come up with

Regards, Mirko



 Comments   
Comment by Ugo Cei [ 15/Dec/04 ]

I have the same problem even if there is no authentication. On the "public" instance, only the first access to a page succeeds, following accesses get only a blank page and the following stacktrace in the logs:

org.apache.slide.jcr.core.NodeImpl 07.12.2004 13:28:09 – ERROR – failed to resolve path relative to /
org.apache.slide.jcr.core.MalformedPathException: '' is not a relative path
at org.apache.slide.jcr.core.Path.parse(Path.java:793)
at org.apache.slide.jcr.core.Path.create(Path.java:102)
at org.apache.slide.jcr.core.NodeImpl.getNode(NodeImpl.java:1413)
at info.magnolia.cms.core.NodeData.<init>(NodeData.java:73)
at info.magnolia.cms.core.HierarchyManager.getNodeData(HierarchyManager.java:305)
at info.magnolia.cms.Aggregator.getRequestedContent(Aggregator.java:117) at info.magnolia.cms.Aggregator.collect(Aggregator.java:166)
at info.magnolia.cms.servlets.EntryServlet.doGet(EntryServlet.java:117)
....

Comment by Sameer Charles [ 15/Dec/04 ]

Ugo, your problem is not the same.
check cache configuration on public instance, I think you have a wrong domain defined there.
domain must point to itself.


problem with secured URI, I tested again and seems to work, but ll test on windows server.
will fix it asap

Comment by Ugo Cei [ 15/Dec/04 ]

I set the value for the /server/cache/level1/domain node to the hostname of the public instance, both with and without http:// in front, but I still get the same blank page and stacktrace.

Comment by Ugo Cei [ 15/Dec/04 ]

Now I got it to work, somehow, by disabling the cache. I still get the stacktrace but the page is shown. The problem now is that it is very slow.

Comment by Sameer Charles [ 17/Dec/04 ]

I dont think there is any bug. perhaps same problem as other people had with wrong domain in cache mappings.
it works seamlessly, tested on osx and windows 2000 server

Generated at Mon Feb 12 03:15:31 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.