#3, #4, and all of the weird specifics for the Confluence implementation have demonstrated that depending on Jira and Confluence to have RelayState or os_destination present and correct is not ideal. It's used inconsistency and sometimes isn't even set.

To solve this, I think it might be ideal to change how the script approaches the issue of knowing where the user was before they were redirected. It seems that it was foolish to believe that Jira and Confluence would consistently tell me where the user was. It would be better to just have the script keep track of it on its own by keeping the last loaded page URL in the session storage.

One issue I see with this approach is if I was to only record what page the user was on, it would require the Jira/Confluence page to have loaded before the user is directed to a login screen. While this would account for a case like #4, it would not account for cases where a user clicked a bookmark and was immediately taken to the login screen. It seems I need to take a mixed approach to the logic. Alternatively, I could choose to keep the script's current approach and only use this new method in cases like #4 where RelayState isn't set but there was a page the user was just on.

Note to self: This warrants a major version increase.

After signing into Okta and returning to Jira or Confluence, it can take upwards of a second or two to be redirected to the correct page. This is kind of bothersome to watch. Investigate if using // @run-at document-start in the userscript metadata reduces this waiting time.

If I try to click a confluence link that has a page anchor in the URL, I'm not redirected to that anchor after I sign in.

When looking at, say, the active sprints page (which begins with /secure/RapidBoard.jspa), if the session expires two things can happen.

1. There will be a prompt at the top right of the screen saying you need to log in again. If you click this, the RelayState parameter will be set (although it won't start with a slash for some reason which is now accounted for in #3).
2. You will be instantly redirected to the login page and RelayState won't be set so there's no way for the script to be aware that the user was just forced to the login page. That means that in its current state, atlast-okta has no way to help with this.

Number two seems to happen to me much more frequently which makes this pretty annoying.

Right now, the dist copy is put on the release branch. I don't like this. Let's use GitHub's release feature.

Example URLs:
https://github.com/IncPlusPlus/atlast-okta/releases
https://github.com/IncPlusPlus/atlast-okta/releases/latest
https://github.com/IncPlusPlus/atlast-okta/releases/latest/download/atlast-okta.meta.js
https://github.com/IncPlusPlus/atlast-okta/releases/latest/download/atlast-okta.user.js

If I try to visit https://jira.ExampleCompany.com/secure/Dashboard.jspa?selectPageId=12345, I am redirected to https://jira.ExampleCompany.com/okta_login.jsp?RelayState=/secure/Dashboard.jspa. Userscripts aren't able to intercept an HTTP 301/302 redirect. So, the script is only able to begin running once the Okta sign-in page is reached. However, the URL at that point no longer has the page ID that the user should be returned to.

Because of this, a useless redirect occurs after the user finishes signing in as they are redirected back to the dashboard on no specific page. It's unfortunately not possible to work around this without turning this project into a chrome extension. As such, I'll leave this bug open as wontfix as this is a problem on Atlassian's end.

The only thing I can do is detect if something like this happens and avoid adding a bit of delay to the page load by redirecting to the same exact page that the user is on. This could be detected by checking if the intended destination page is the same as the current URL.

Action items:

• Detect if a redirect is useless and, if so, don't bother redirecting the user
• Update the README with a limitations section that describes this issue