The recent change to make getScriptUrl return relative URLs affects TWiki's redirection mechanism as well - it now is generating relative URLs on oops redirections.
RFC2616 requires an absolute URI in the Location header, however, relative URIs seem to work in all browsers, therefore it doesn't make it to the top of my todo list....
Further: when one uses %SCRIPTURL{...}%, what is expected is that we have
an URL
as result, and an URL is necessarily in the form
protocol://host/path
. If one wants only the path
to something, he/she willl use %SCRIPTURLPATH{...}%.
IMHO, returning a path (which is not a URL) when one expects an URL is quite wrong.
I'm raising this issue to "normal" status.
AT
Actually this bug is very clear. See test case below.
%SCRIPTURL%
%SCRIPTURL{"viewauth"}%
expands to
https://develop.twiki.org/do
https://develop.twiki.org/do/viewauth
to the shortform works and the form with a parameter works like if it had been SCRIPTURLPATH
This does not break compatibility with Cairo because the parameter form did not exist in Cairo - but it is still a nasty bug with several consequences. Se
Item1170.
KJL
And it completely breaks registration. The email I received was:
From: TWiki Administrator <webmaster@limbo-randy2.dreamhost.com>
Date: 12-Dec-2005 20:48
Subject: How to activate your TWiki registration
To: TestUser <Martin@cleaver.org>
Thank you for registering in the TWiki collaboration platform. Your verification code is TestUser.4976.
You now need to verify your email address. You can do so by entering 'TestUser.4976' in the form presented to you when this email was sent, or by visiting /twiki/bin/register?action=verify;code=TestUser.4976
Note:
If you got this email by mistake: Somebody (TestUser) registered at the TWiki site using your mail address Martin@cleaver.org. Contact webmaster if this is in error.
Note the link /twiki/bin ... this must be prefixed by
http://.../
--
MC
This problem - links in emails are rendered as relative links - was what made me discover the problem in the first place. In the meantime I've figured out how to solve it: Wrap the routine which prepares the email template (in
Register.pm
,
sub _sendEmail
) between the two lines
$session->enterContext('absolute_urls');
...
$session->leaveContext('absolute_urls');
So what remains to be solved is how to tell TWikis own redirect methods that it has to create absolute URLs.
--
TWiki:Main.HaraldJoerg
As documented %SCRIPTURL%
always generates an absolute URL, for compatibility with Cairo, and %SCRIPTURL{"script"}% generates a relative path
if it can.
The bug is not at all clear. Harald's solution uses
code to distinguish relative and absolute URLs. Antonio's solution uses
templates (the
PATH variants). It's not in the least bit clear what the "right" way to work is. Personally I think it's easier to specify in code, and dump the *PATH variants in the templates, so that's what I've been trying to do. However for compatibility, %SCRIPTURL% (which should be regarded as deprecated) has to always generate an *absolute path.
I was trying to dispense with the distinction between "URL" and "URLPATH" due to the confusion it has clearly caused (they were misused throughout the code and the templates). This has to be an either-or.
Either specify absolute URLs in code, and write templates using a normal form,
or specify rel/abs in templates, and dispense with the code. Given the abuse that has occurred in templates before now, I favour keeping it simple for the template author.
SVN 7851 has the code to force absolute urls in redirects and mail generation.
CC