Bug #66881
closed
Link from MS Word leads always to home.html
0%
Description
This report is about TYPO3 CMS 6.2.12 with PHP Version 5.4.27 on a UNIX server.
Context¶
- Our employees sometimes exchange MS Office 2010 Word documents where they have several links to protected pages of a TYPO3 CMS 6.2.12 website.
- The website has a login feature which works like the following:
0. User wants to call a URL to a protected page of the website mentioned above.
1. She/he lands on the login page and in browser you have URL: http://typo3installation.com/home.html?referer=<path_to_protected_page>
2. After providing her/his login data she/he will get redirected to the protected page.
Description¶
[Case A]
We assume that the user is not logged in to the TYPO3 website mentionend above.
If the user subsequently clicks several links to protected pages from a MS Office 2010 Word document the following happens:
1. First link: Same behavior mentioned above by steps 0 to 2. Keep in mind that user now is logged in.
2. Second and all other links: User always gets redirected to the following URL http://typo3installation.com/home.html?referer=<path_to_protected_page>, but she/he is already logged in...
----> hence she/he can never reach the page.
[Case B]
We assume that the user is logged in to the TYPO3 website mentionend above.
If the user subsequently clicks several links to protected pages from a MS Office 2010 Word document the following happens:
Every link (so also the first link) leads to http://typo3installation.com/home.html?referer=<path_to_protected_page> --> hence user never reaches the wished page.
Our current fix:¶
We have put on the page where the login is a little plugin doing the following in its controller:
if ('' !== GeneralUtility::_GET('referer') &&
is_string(GeneralUtility::_GET('referer')) &&
NULL !== $GLOBALS['TSFE']->fe_user->user &&
isset($GLOBALS['TSFE']->fe_user->user['username']) &&
!headers_sent()) {
$this->redirectToUri(GeneralUtility::_GET('referer'));
exit;
}
Please have a look onto this as I think it is crucial for a CMS to have a proper link handling.
PS:¶
Calling the links to protected pages from a simple html document works.
Updated by Mathias Schreiber over 9 years ago
- Status changed from New to Accepted
- Assignee set to Mathias Schreiber
Hi Christian,
Why can't you use the solution in place?
http://docs.typo3.org/typo3cms/extensions/felogin/Examples/Index.html
You link to the access restricted page and TYPO3 takes care of the rest
Updated by Markus Klein over 9 years ago
For exactly this scenario we have a pageNotFound-Handler in place. We simply link the protected page directly. The handler is called if such a page is hit and no valid user is logged in. We simply redirect to the login page in the handler.
Updated by Mathias Schreiber over 9 years ago
- Status changed from Accepted to Needs Feedback
Updated by Christian Huppert over 9 years ago
Hi Markus,
For exactly this scenario we have a pageNotFound-Handler in place. We simply link the protected page directly. The handler is called if such a page is hit and no valid user is logged in. We simply redirect to the login page in the handler.
This handling is okay and works perfectly.
The point in my description is that the user is already logged in.
If it calls the protected page from a link in a HTML document it works correctly.
BUT:
If it calls the protected page from a MS Office 2010 Word document it gets redirected to the login page which it shouldn't. As it is already logged in
it should go to the protected page but it doesn't. Maybe you can check this by your own using a MS Office 2010 Word document to verify (or even falsify) my description.
@Mathias:
I will give your solution a try but I have the feeling that it will not change the behavior as the problem is the source (html vs. not html) from where I call the link from.
See my description I gave here to Markus.
Updated by Anonymous over 9 years ago
I can confirm this problem, although in our case, we don't have a pageNotFound handler implemented. Clicking on a link in Word to a protected page in TYPO3, even when the FE user is logged-in, results in a 403 error IN WORD ITSELF. The cmd+click doesn't even get as far as the browser. I'm assuming that Word pre-checks the availability of the URL before trying to open it in the browser.
Updated by Markus Klein over 9 years ago
- Assignee deleted (
Mathias Schreiber) - Priority changed from Must have to -- undefined --
@Mark thanks for that info. I suspected that already. Word is doing a pre-check on the link.
@Christian:
That would also explain your issue. Word accesses the protected page (without login of course) and gets the redirect to home.html and finally leads the user to this page.
IMHO there is no way to fix this in TYPO3 CMS.
Updated by Christian Huppert over 9 years ago
Hi Markus and Mark,
thank you for clarifying this issue.
@Mark:
How could you see that the error was in Word itself? Just for curiosity how you detected that. ;-)
@Markus:
What do you think about the fix which we use especially for these Word links in our developed dedicated extension for this:
if ('' !== GeneralUtility::_GET('referer') &&
is_string(GeneralUtility::_GET('referer')) &&
NULL !== $GLOBALS['TSFE']->fe_user->user &&
isset($GLOBALS['TSFE']->fe_user->user['username']) &&
!headers_sent()) {
$this->redirectToUri(GeneralUtility::_GET('referer'));
exit;
}
Maybe you could merge this snippet into the TYPO3 CMS Core to prevent these Word issues - if possible or senseful?
Updated by Markus Klein over 9 years ago
I'm not sure where you wanna put that. But I have doubt that this makes sense at all. You basically say: If we have a referrer and a valid FE user do some redirect. I can imagine that most people wouldn't like this as a general behaviour.
Updated by Christian Huppert over 9 years ago
Hi Markus,
ok, you are right. I did not had the view on all users in my mind.
Then you should not merge it in the core and you can close this ticket.
Thank you for your support.
gr. Christian
Updated by Markus Klein over 9 years ago
- Status changed from Needs Feedback to Closed