Profile/User - Invalid URLs with SSL-Access

[gap]

Hi,

if I call the website from SSL-Host, links to *Users Profiles* contain an invalid URL:

 https://zikula.technixen.net/https://zikula.technixen.net/index.php?module=Profil&func=view&uname=USER

I configured _no extra_ SSL-Host, because the Domainname stays the same:

 http://zikula.technixen.net/
 https://zikula.technixen.net/

But it doesn't func with configured SSL-Host also. (Tested this)

[Guite]

Isn't this more a problem with configuration on server level?
What does "it doesn't func" mean?

[gap]

Replying to Guite:

Isn't this more a problem with configuration on server level?

I don't think so, because I elsewhere have no problem,
but only here with this module.

What does "it doesn't func" mean?

It means, the created links are not correct,
if the websites URLs start with " https://"

[drak]

Would you provide me with a test environment to replicate the problem please?

you can email me at drak at zikula...

[Landseer]

Any information here to help us finding the problem? Does it happen with Profile/Users? only?

[gap]

3 months ago I wrote to drak as you told me to. Got no answer from him yet.
The *testcase* is here:  https://www.technixen.net/ Any female Zikula developer may register an account and see ;)

[Landseer]

Replying to gap:

3 months ago I wrote to drak as you told me to. Got no answer from him yet.
The *testcase* is here:  https://www.technixen.net/ Any female Zikula developer may register an account and see ;)

Two problems in this case:

• the site is using an invalid certificate, issued to webserver.ispgateway.de instead of technixen.net or zikula.technixen.net
• there is no woman in the dev team, so the bug has to remain unfixed ;-)

[lunarchild]

Replying to Landseer:

Two problems in this case:

• the site is using an invalid certificate, issued to webserver.ispgateway.de instead of technixen.net or zikula.technixen.net
• there is no woman in the dev team, so the bug has to remain unfixed ;-)

I just made a local install, work's fine but on 'Who's online' block this case as described from ticket-opener happens if SSL is enabled.

non-SSL:  http://dev.lc-srv.net/zikula/Profile/view/Lunarchild
with-SSL:  https://dev.lc-srv.net/zikula/https://dev.lc-srv.net/zikula/Profile/view/Lunarchild

It correctly display's the link to user profile(s) on non-SSL, but with it doubles the hostname.

https://dev.lc-srv.net/https://dev.lc-srv.net/
https://zikula.technixen.net/https://zikula.technixen.net/

IMHO it's not because a misconfigured webserver, corrupted or invalid certificate - something like this should not cause the php-interpreter or zikula to make differend output to the client side, as this problem may is caused in the 'Users' module or where the link is prepared for output.

[lunarchild]

Ok, I think i know why this happens after a short research.

In the file '/system/pnRender/plugins/modifier.userprofilelink.php' there is the function smarty_modifier_userprofilelink, which is preparing the links to the profile's. Interesting are line's 67 + 70 where the parts of each link get together.

        if (strpbrk($string, '/:#')=='') {
            $string = '<a' . $class . ' title="' . DataUtil::formatForDisplay(_PROFILE)
             . ': ' . $string . '" href="' . pnGetBaseURL()
             . DataUtil::formatForDisplay(pnModURL($profileModule, 'user',  'view', array('uname' => $string)))
             . '">' . $show . '</a>';
        } else {
            $uid = pnUserGetIDFromName($string);
            $string = '<a' . $class . ' title="' . DataUtil::formatForDisplay(_PROFILE)
            . ': ' . $string . '" href="' . pnGetBaseURL()
            . DataUtil::formatForDisplay(pnModURL($profileModule, 'user', 'view', array('uid' => $uid)))
            . '">' . $show . '</a>';
        }

In this constellation 2 functions may prepend the protocols - pnGetBaseURL() + pnModURL()

The first enforces it, but the second does prepend it only if there some cases as mentioned for documentation in the providing file for this function (/includes/pnMod.php), for example if ssl is on we get doubled hostname.

[Landseer]

see also #1095 (closed as duplicate)

[Simon]

This fragment from pnModURL is relevant:

830     // Only produce full URL when HTTPS is on or $ssl is set 
831     $siteRoot = ''; 
832     if ((isset($https) && $https == 'on') || $ssl != null || $fqurl == true) { 
833         $protocol = 'http' . (($https == 'on' && $ssl !== false) || $ssl === true ? 's' : ''); 
834         $secureDomain = pnConfigGetVar('secure_domain'); 
835         $siteRoot = $protocol . '://' . (($secureDomain != '') ? $secureDomain : ($host . $baseuri)) . '/'; 
836     } 

A full URL is automatically created if HTTPS is on. We simply need to amend the above quoted lines from modifier.userprofilelink.php to remove the call to pnGetBaseURL().

[ph]

Well, now this is interesting (or not). Currently, the Profile module must be set (in admin settings) for modifier.userprofilelink.php to 'generate' the URL. But ironically, in SVN this setting does not even exist anymore: the Profile module can not be set, thus a link is not being generated by the pnRender plugin.
Anyway, I think the problem described in this ticket is the following.
In modifier.userprofilelink.php, the link is being put together like this:
pnGetBaseURL() . DataUtil::formatForDisplay(pnModURL($profileModule, 'user', 'view', array('uname' => $string)))
Now pnModURL will generate a full URL only if ssl is enabled, else a relative URL will be returned. This makes the prepending pnGetBaseURL() useless. When stripping this, a valid link will always be generated.
But, due to the check for a Profile module, which does not exist in current SVN version, no link will be displayed at all :D

[Landseer]

...which is correct, because if there is no Profile module (of any kind) installed a link to a profile doesn't make sense.

But it is correct that adding the pnGetBaseURL() to the url in the modifier is wrong. This should ensure a fully qualified url, but we have a special parameter in pnModURL() for this. Iirc this has been fixed in my local system, but not yet committed.

[drak]

Frank, please commit the fix.

[mateo]

Feedback is required to see if this is finally fixed.

What I know, is that recently I've reviewed out stuff to release 1.2 and I fixed the userprofile modifier issue, would be good to know if there's any bug like this when SSL is enabled.

Closing this... can be reopened if the issue persists.