tryLoginCodeFlow with HashLocationStrategy

[bigozzi-inspect]

The screen shows like this line of code this.parseQueryString(window.location.search) can't work with HashLocationStrategy because query string is inside windows.location.hash rather than window.location.search.

Thanks you for this nice lib!

[bigozzi-inspect]

This is a ugly fix:

public tryLoginCodeFlow(): Promise<void> {

    const parts = this.parseQueryString(window.location.search ||
        window.location.hash.split('?').pop())
    [...]
}

In this file: https://github.com/manfredsteyer/angular-oauth2-oidc/blob/master/projects/lib/src/oauth-service.ts
Line: 1400

[jeroenheijmans]

Thx for sharing! But your issue is really rather hard to follow. Could you please elaborate, (is it a bug? a question? could you create a minimal repro? what is the expected vs actual outcome after a set of steps to reproduce?).

[bigozzi-inspect]

Thx for sharing! But your issue is really rather hard to follow. Could you please elaborate, (is it a bug? a question? could you create a minimal repro? what is the expected vs actual outcome after a set of steps to reproduce?).

Hi @jeroenheijmans, i have edited bug description and fix comment, i hope now it's more comprensible!

[manfredsteyer]

Thx for this info. According to the specs, code flow transports the code in the querystring. However, there is this additonal spec, that allows us to vary the the response_mode to hash:

https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html

I guess, we should look into it for the next version.

[manfredsteyer]

Btw: Could be a nice PR ...

[gingters]

@jeroenheijmans With all due respect, but I consider this a bug, and not a feature request.

This is an oidc library for angular applications, and while not being the default, angular provides the hash location strategy out of the box and it is commonly used. So every developer of an angular lib should be very aware that query strings in an angular application can come after a hash.

+++
Edit Additional info:
That has nothing to do with the response type. You'd simply set the redirect uri on the IDP to https://domain/app/#/login-callback-component and then the idp will simply append the code to the query string after this url and will call back into the angular app using hash location strategy. In this case the library isn't capable of reading the code from the url and do it's thing at all.
+++

A more angular-like approach would be to have the ActivatedRoute injected in the OAuthService and use this.route.snapshot.paramMap.get('paramName') to access the query parameters in a unique fashion regardless of the configured location strategy.

[jeroenheijmans]

Something has to be changed in a PR to make a specific scenario work, I'm not too fussed whether we label it a 'bug' or a 'feature' 😄 - I've changed the label.

[gingters]

Hehe, I mean, there is a claim on the readme stating that its tested with hash location strategy ;)
I will try to get something done here.

[jeroenheijmans]

Hah fair point :)

I think the readme is from some time ago, and the Code Flow was integrated via community-provided PRs that omitted this part.

Would be nice if you could add a PR. (Note that while I try to keep an eye on GH issues, it's Manfred who typically takes some time every few months to merge PRs and create a new release. So could take a bit before anything gets integrated.)

[gingters]

I will ping Manfred. Hope he can get a bugfix release out a tad faster ;)