Uploaded image for project: 'Crucible'
  1. Crucible
  2. CRUC-6683

Review comment @mention e-mails contain wrong URL

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Low Low
    • None
    • 3.0.2, 3.1.5
    • None

      Problem

      If you have a https:// site URL configured for your Crucible instance and you mention an user in a review comment, the notification e-mail will contain a link to the comment with http:// protocol, regardless if you have the site URL configured with https://

      Steps to reproduce

      1. Set up a Crucible instance running over HTTPS: https://confluence.atlassian.com/display/FISHEYE/FishEye+SSL+configuration or you can simply use a reverse-proxy with HTTPS
      2. Add two users and create a review
      3. Add a comment to the review, with mentioning one user with the other within the comment
      4. Notice that the link to the comment contains http:// link, whereas all other links in the e-mail contain the protocol properly with https://

          Form Name

            [CRUC-6683] Review comment @mention e-mails contain wrong URL

            Nick added a comment -

            pkoczan so is the link that is wrong for the

            contain a link to the comment with http:// protocol,

            or

            only for the review link

            ?

            Are you saying that this is caused by the fact that the site url was changed AFTER an entry was added to the cru_notification table ?

            Nick added a comment - pkoczan so is the link that is wrong for the contain a link to the comment with http:// protocol, or only for the review link ? Are you saying that this is caused by the fact that the site url was changed AFTER an entry was added to the cru_notification table ?

            Peter Koczan (Inactive) added a comment - - edited

            Hi npellow, nope, I mean the notification remains on the same URL for this particular review, however long after the site URL has been chaged. I have my site URL on https for a few days now and for this particular review that was created when I had the non-https site URL still sends notifications (only for the review link) with the non-https URL

            Peter Koczan (Inactive) added a comment - - edited Hi npellow , nope, I mean the notification remains on the same URL for this particular review, however long after the site URL has been chaged. I have my site URL on https for a few days now and for this particular review that was created when I had the non-https site URL still sends notifications (only for the review link) with the non-https URL

            Nick added a comment -

            pkoczan - Ok, that makes sense then. There would be a small window where if the notification is not sent immediately and you change the Site URL, then the email will be incorrect.
            I can't see a lot that can be done about this. (What if you read the email after the SITE URL changes too ?).

            Was the root cause of the customer, the same as yours ? If so, I suggest we close this issue out?

            Nick added a comment - pkoczan - Ok, that makes sense then. There would be a small window where if the notification is not sent immediately and you change the Site URL, then the email will be incorrect. I can't see a lot that can be done about this. (What if you read the email after the SITE URL changes too ?). Was the root cause of the customer, the same as yours ? If so, I suggest we close this issue out?

            Hi Nick,

            I think I found out why you did not manage to reproduce it and I did. I originally set up this instance without a https:// URL, I only added that via a reverse proxy, to reproduce this issue. The review I was using was created with the old site URL and probably the watch entry was added during that time too. So now if I query the cru_notification table, I can still see the old non-https cru_object_url for the notification, I suspect, this is where it is coming from in my case.

            Let me know if you want my DB dump for the current state.

            Peter Koczan (Inactive) added a comment - Hi Nick, I think I found out why you did not manage to reproduce it and I did. I originally set up this instance without a https:// URL, I only added that via a reverse proxy, to reproduce this issue. The review I was using was created with the old site URL and probably the watch entry was added during that time too. So now if I query the cru_notification table, I can still see the old non-https cru_object_url for the notification, I suspect, this is where it is coming from in my case. Let me know if you want my DB dump for the current state.

            Nick added a comment -

            I am unable to reproduce this issue.

            The Site URL and Proxy configurations are set, with a bind address to localhost:

            Site URL: https://fisheye.dev.internal.atlassian.com
            Site proxy host: fisheye.dev.internal.atlassian.com
            Site proxy scheme: https
            Http bind: 127.0.0.1:8060

            The attached screenshot containing an @mention EMAIL, shows the correct http value is used.

            Nick added a comment - I am unable to reproduce this issue. The Site URL and Proxy configurations are set, with a bind address to localhost: Site URL: https://fisheye.dev.internal.atlassian.com Site proxy host: fisheye.dev.internal.atlassian.com Site proxy scheme: https Http bind: 127.0.0.1:8060 The attached screenshot containing an @mention EMAIL, shows the correct http value is used.

              Unassigned Unassigned
              pkoczan Peter Koczan (Inactive)
              Affected customers:
              1 This affects my team
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: