Ingo Könemann created OFBIZ-12047:
-------------------------------------

             Summary: Remove _PREVIOUS_REQUEST_ Session Attribute on 
non-authentication pages
                 Key: OFBIZ-12047
                 URL: https://issues.apache.org/jira/browse/OFBIZ-12047
             Project: OFBiz
          Issue Type: Improvement
            Reporter: Ingo Könemann
            Assignee: Ingo Könemann
             Fix For: Release Branch 18.12


There is a session attribute called "_PREVIOUS_REQUEST_" used to remember and 
execute the previous request after a login occurs. This attribute is not 
removed properly when navigating away from a page without logging in.

When navigating to a page that requires authentication the "_PREVIOUS_REQUEST_" 
attribute is saved in the session from within the LoginWorker to be called 
again when the login was successful through the RequestHandler. Currently, the 
attribute is only removed when a login occurs resulting in the previous request 
being stored in the session until some form of login is successfully executed.

This behavior potentially results in navigation problems since a user is able 
to navigate to a page requiring authentication without logging in. An old 
request will be pulled from the session when a similar event occurs and the 
user logs in.

 

I propose to have the RequestHandler remove the session attribute 
"_PREVIOUS_REQUEST_" after calling a request that does not require 
authentication. We also have to restructure the sequence of request handling to 
have the "targetRequestUri" handled after the security check and a possible 
removal of the session attribute.

 

One problem arises with this solution, however, which should be less of an 
issue than the current state:

If the login page includes a request call that is handled after the request 
showing the login page (for example an ajax call rendering a screen), the 
"_PREVIOUS_REQUEST_" attribute will be lost before the login is processed. To 
my knowledge such a case does not exist within the OFBiz environment and seems 
to be an edge case far less problematic than the above mentioned problem.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to