I don't always want the hash restored

[jacobweber]

Currently, when you make an auth request, JSO stores the current window's hash, and restores it when you call jso_checkfortoken.

But I don't always want this. For example, I'm opening the login page in an iframe, using jso_registerRedirectHandler, and then manually checking for a token in the callback page, with jso_checkfortoken. This is similar to your "Using JSO With Phonegap" example.

So the hash of the main window shouldn't be changed by the OAuth process. If I change it for my own purposes, JSO will restore it, which it shouldn't do.

Maybe there should be a configuration to avoid restoring the hash?

[ikogan]

Are you still using this, including your IFRAME code? If so, I don't suppose you could make it public/file a pull request with it?

[jacobweber]

I got this to work by modifying JSO, so that if you use jso_registerRedirectHandler, it skips the code that restores the hash. So I added a custom_redirect variable to the variables on top:

        custom_redirect,
        api_redirect,
        ...

And in jso_registerRedirectHandler, I set it to true:

    exp.jso_registerRedirectHandler = function(callback) {
        custom_redirect = true;
        api_redirect = callback;
    };

and in the part of jso_checkfortoken that checks state.restoreHash, I make sure it's not true:

        if (!custom_redirect) {
            if (state.restoreHash) {
                window.location.hash = state.restoreHash;
            } else {
                window.location.hash = '';
            }
        }

[cstickel]

Also highly interested in a fix for this problem. Especially because IE11 adds a # for window.location.hash = ''; even if there was no hash value before. And the angular router will freak out if the href is changed while routing.
Is there a reason why the PR of @arithmetric didn't got merged? If help is needed to solve this, i would be happy to do a PR, if you tell me if it does has a chance to get merged @andreassolberg