Skip to content

sessionCheckEventListener logs wrong origin whenever changed is detected #447

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ggjersund opened this issue Oct 4, 2018 · 6 comments
Closed
Labels
bug For tagging faulty or unexpected behavior.

Comments

@ggjersund
Copy link

I've tried following the advice given in #283 #257 however I still can't seem to solve the issues.

The local setup I am running is an Open ID Connect Provider written in Django at http://127.0.0.1:8000/openid/. Angular is served at http://localhost:4200.

The following error is what I get in the console:

skjermbilde 2018-10-04 kl 21 07 02

Also a more detailed overview

skjermbilde 2018-10-04 kl 21 14 22

So my question is simply, is there a way to fix this wrong origin problem?

@manfredsteyer
Copy link
Owner

Thanks for this. Can you compare you example with the demo application? There is effect does not occur. What's different there?

@ggjersund
Copy link
Author

ggjersund commented Oct 5, 2018

@manfredsteyer My own Angular application is requesting a different response_type than the sample one. My application is requesting id_token token and the sample application is requesting token. The problem is that only token is not valid for my own backend. So where is this configured? I'm currently using the exact same config.

@ggjersund
Copy link
Author

ggjersund commented Oct 5, 2018

Possibly related to the newest update in #397?

This is what my provider returns from discovery document:
skjermbilde 2018-10-05 kl 14 21 46

Yet, the response_type used is token.

@manfredsteyer
Copy link
Owner

It must be sth different. The client is also using id_token token. However, it's set dynamically at runtime b/c the user can control with the checkbox wether to go with id_token or id_token token.

@ggjersund
Copy link
Author

ggjersund commented Oct 10, 2018

@manfredsteyer If you'd like to test what I mean you can try the demo application I created here. There seems to be a problem running in on stackblitz, so I suggest downloading and running it locally.

@jeroenheijmans jeroenheijmans added the bug For tagging faulty or unexpected behavior. label Nov 17, 2019
@manfredsteyer
Copy link
Owner

If the origin is not the right one, it's likely we received a different message which is not about token refresh (e. g. silent refresh or something different going on in the SPA). Hence, you can ignore this debug info.

We can solve this by also sending and checking a message-type. Currently, we first check the origin and than try to make sense of the received playload.

With version 9.1 - which lands quite soon - session checks will also work with code flow. Please have a look to the docs when it lands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug For tagging faulty or unexpected behavior.
Projects
None yet
Development

No branches or pull requests

3 participants