Task #45361: Make "Neos_lastVisitedUri" Cookie obsolete - TYPO3.Neos - TYPO3 Forge

Base Distribution TYPO3.Form TYPO3.Imagine TYPO3.Media TYPO3.Neos TYPO3.Neos.NodeTypes TYPO3.Party TYPO3.Setup TYPO3.SiteKickstarter TYPO3.Twitter.Bootstrap TYPO3.TYPO3CR TYPO3.TypoScript Coordination Group Website and Communication

Task #45361

Make "Neos_lastVisitedUri" Cookie obsolete

Added by Adrian Föder over 2 years ago. Updated over 2 years ago.

Status:

Resolved

Start date:

2013-02-11

Priority:

Should have

Due date:

Assigned To:

Adrian Föder

% Done:

100%

Category:

Target version:

Description

Since it's at least for caching not a good practice to have cookies around, it would be worthwhile to renounce this cookie.

An idea would be to use localStorage; however this is not that easy to pass to the server like a Cookie is.

One solution would be to add the localStorage value to a hidden field in the login screen, making it available for the redirect.

Then the value should be stored in the user preferences or the flow session, so that the redirect would work when accessing /neos and already being logged in. This would mean that the redirect wouldn't necessarily go to the last visited page in the frontend when logged in, but the last visited page before logging in. We could possibly update the flow session / user preference when navigating pages and being logged in.

Another solution would be to make the redirect client based and use JavaScript to do the actual redirect combining the value of localStorage and the workspace name. This has the drawback of having to run JavaScript for the redirect and also the drawback of being unable to check whether a page exists or not before redirecting to it.

I think we should go with the first solution.

Related issues

Associated revisions

Revision 781f44ce
Added by Adrian Föder over 2 years ago

[TASK] Refactored backend login/logout code

This introduces a BackendRedirectionService which is responsible for
the redirections after a backend login or logout.

For redirecting an editor "back" to the frontend page where he came
from before logging in, a session key ``lastVisitedUri`` is maintained.
Using the browser's sessionStorage it stores the user's last visited URI
to the session (see I31d77af758cc938e68952344315546d9a7c9379b).

On logout, the content editor's last visited URI has the namespace
indicator (``@``) removed and the editor is redirected to that URI.

Resolves: #45361
Related: #40304
Change-Id: I964f0d1dc05b14e8bc6e0b866583513b91e08769

Revision 21017f40
Added by Aske Ertmann over 2 years ago

[TASK] Use try catch statement for session storage check

The check for the last visited url in the login should use
the same as the content types package which is equal to how
it's done in Modernizr.

Change-Id: I90931b291a170b7efc019fad4a484ed5e436b28a
Related: #45361

Revision d777663f
Added by Robert Lemke over 2 years ago

[BUGFIX] Fix recording of last visited node for sub requests

The aspect introduced in I964f0d1dc05b14e8bc6e0b866583513b91e08769
assumes that the current request is the main ActionRequest, which
is not the case if a widget is rendered. In that situation Neos would
fail with this error message:

Fatal error: Call to undefined method TYPO3\Flow\Mvc\ActionRequest::getUri()
in TYPO3_Neos_Aspect_LastVisitedNodeAspect.php on line 55

Since aspects are more expensive and the introduced aspect only
advised a single method in a single controller, I moved the behavior
to the end of the showAction() and removed the aspect again.

Change-Id: Ie00a40781f0b5375e4b3ee1a8d4c7c1e548bf5fa
Related: #45361

History

#1 Updated by Aske Ertmann over 2 years ago

Status changed from New to Accepted
Assigned To set to Adrian Föder

#2 Updated by Adrian Föder over 2 years ago

before deciding how to technically implement it; how is it intended to work at all?

I make the following assumptions:

When logging out from the backend, the editor should be redirected to a specified page.
This specified page should be the last page the editor visited.
What does visited mean? The last page before logging in or the last page he had visited even logged in, i.e. in order to edit it?

If I'm right so far, the final question is:

Should the user be redirected to where he initially came from prior logging in, just as if the backend visit never occured,
or should the user be redirected to the page he last had open in Backend, just as if he would like to check, see, verify his work?

#3 Updated by Christian Müller over 2 years ago

I think the use case was rather to end up on the page you last visited after logging in. It was not so much for after being logged out. Just from the assumption that someone browses the website and decides to change a page if she sees something needs to change, so she should end up on that page after login.

#4 Updated by Rens Admiraal over 2 years ago

Christian: think you're not fully right... The cookie is set in the backend controller, not in the frontend. And IMHO it would be bad to track a cookie in te frontend before a login happens. Besides that it won't be possible to store the referer I guess as we don't know the last page visited (we would only know that if the user clicks a link right?).

I do agree to changing the behaviour though... Localstorage would be fine for this, and injecting it in the login form (as suggested on IRC) would be a good entry point.