On a site where some users browse on https protocol and some on http, the default site activity feed of Heartbeat uses the protocols in links incorrectly. It seems that the links for user's activity have the protocol hardcoded in them based on how the user in question was surfing.

A correct behavior would be for Heartbeat not to save this protocol information and to let the protocol links be determined by the user's browser, as with other links in Drupal.

Example:

  1. User A logs in through https and sees the site activity feed.
  2. The feed reads:
  3. User B has updated page "node 5". (bolded parts are https links as user B was browsing on https)
  4. User C has added page node 5. (bolded parts are http links as user C was browsing on http)
  5. User D's and User D's account pages have been changed. (The other link is https and the other isn't, please see below)
  6. If User A clicks on the links about User C's activity, he will see the page of node 5 as an anonymous user. In case the site is configured to show content only to registered users, he will get an Access Denied error message.
  7. In a case when a user registered through http and got in email a login link that was https, the case from above occurred: activity feed displayed his name twice as though they would have been different accounts that had been changed. One's link had http protocol prefix and the other had https.

Comments

Stalski’s picture

Stalski commented
Status: Active » Needs work

This is certainly true. I only should see again why I did this. There was a reason for the absolute urls.

Daedalon’s picture

Daedalon commented

Apart from #698426: System URL being used. Not the Alias. where we've discussed formatting URL in runtime instead of saving the absolute, I can imagine some reasons for wanting to save the absolute URL but not with the protocol prefix. If there are reasons I'm interested to learn of them, but so far I can't think of an internal Drupal page being accessible only via http or https. Instead there's a Context SSL module that redirects to https if necessary (good for admin/*).

Stalski’s picture

Stalski commented
Version: 7.x-1.0 » 7.x-1.x-dev
Status: Needs work » Needs review

This should be fixed in dev now. All links (especially the ones rendered and stored from token replacement) are relative now.
I really hope there will be no bug introduced by this.

Daedalon’s picture

Daedalon commented

Great! In WordPress, a common way is to call site_url() to format the URL, which gives the proper protocol prefix and takes the rest of the site's root URL from the site settings.

If something like this is not available with Drupal, another solution would be to use a system variable or constant to get the beginning of the target URL to link to.

Stalski’s picture

Stalski commented

the url and l function does the same thing and was already used. It's the arguments that matter.

so it should work but I need your answer from the review ;)

Daedalon’s picture

Daedalon commented

Works like a charm. Thanks!

I removed the plugin before installing the dev version, so I encountered another problem I hadn't yet reported: the plugin default permissions are too strict. By default, administrators should have the permission checkbox checked for all parts of the plugin. A recommendation to visit the permissions should also be presented to the admins.

Stalski’s picture

Stalski commented
Status: Needs review » Fixed

Ok, I am glad it works.

About that other question. I can only say that permissions always start strict, untill you give access through the UI. Core has an option to enable permissions of enabled modules by default.
If that's not what you meant, please open another issue.

Daedalon’s picture

Daedalon commented

I think that with the same sitewide settings with other plugins I've installed all the permissions have been given to admin initially. Only with Heartbeat I've encountered the situation of admin not seeing the output of the newly-installed and configured plugin.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.