Error state does not match

Help
,
1

I get an error that says that my state does not match, it worked before i upgraded to angular 5 from 4.

Update:

below you can see my dependencies, “angular2-jwt”: “^0.2.3” is getting a warning that i should have angular >4.0.0 but that should not be the problem as the app does not reach JWT… my uri_redirect is http://localhost:5000

error is thrown in handleAuthentication() at this.auth0.parseHash((err, authResult).

What should I check for when it comes to that error? I have also checked token at JWT.io and it looks normal

  auth0 = new auth0.WebAuth({
    clientID: SECRET,
    domain: SECRET,
    responseType: 'token id_token',
    audience: SECRET,
    redirectUri: 'http://localhost:5000',      
    scope: 'openid email profile'
  });

"@angular/animations": "^5.0.1",
"@angular/cdk": "^5.0.0-rc0",
"@angular/common": "^5.0.1",
"@angular/compiler": "^5.0.1",
"@angular/core": "^5.0.1",
"@angular/flex-layout": "^2.0.0-beta.10",
"@angular/forms": "^5.0.1",
"@angular/http": "^5.0.1",
"@angular/material": "^5.0.0-rc0",
"@angular/platform-browser": "^5.0.1",
"@angular/platform-browser-dynamic": "^5.0.1",
"@angular/platform-server": "^5.0.1",
"@angular/router": "^5.0.1",
"@ngtools/webpack": "^1.8.0",
"@types/underscore": "^1.8.4",
"@types/webpack-env": "1.13.0",
"angular-sortablejs": "^2.1.0",
"angular2-chartjs": "^0.3.0",
"angular2-jwt": "^0.2.3",
"angular2-template-loader": "0.6.2",
"aspnet-prerendering": "^3.0.1",
"aspnet-webpack": "^2.0.1",
"auth0-js": "^8.11.2",
"awesome-typescript-loader": "3.2.1",
"bootstrap": "3.3.7",
"chart.js": "^2.7.1",
"css": "2.2.1",
"css-loader": "0.28.4",
"es6-shim": "0.35.3",
"event-source-polyfill": "0.0.9",
"expose-loader": "0.7.3",
"extract-text-webpack-plugin": "2.1.2",
"file-loader": "0.11.2",
"font-awesome": "^4.7.0",
"hammerjs": "^2.0.8",
"html-loader": "0.4.5",
"isomorphic-fetch": "2.2.1",
"jquery": "3.2.1",
"json-loader": "^0.5.7",
"lodash": "^4.17.4",
"ng2-toasty": "^4.0.3",
"ngx-perfect-scrollbar": "^5.0.0-9",
"preboot": "4.5.2",
"raven-js": "^3.19.1",
"raw-loader": "0.5.1",
"reflect-metadata": "0.1.10",
"rxjs": "^5.5.2",
"smooth-scrollbar": "^8.2.0",
"sortablejs": "^1.7.0",
"style-loader": "0.18.2",
"superagent": "^3.8.1",
"to-string-loader": "1.1.5",
"typescript": "^2.4.2",
"underscore": "^1.8.3",
"url-loader": "0.5.9",
"webpack": "2.5.1",
"webpack-hot-middleware": "2.18.2",
"webpack-merge": "4.1.0",
"zone.js": "0.8.12"
2

I already learned the hard way not to exclude any possibility when it comes to software, however, at first glance the upgrade in Angular version should not be causing this. Have you updated any other dependencies at the same time you updated Angular? Independently of that you should also include additional information in the question, ideally enough to have notion of steps to reproduce the issue.

3

Yes I updated dependencies, see edited question.

4

Yes I updated dependencies, see edited question.

5

Given that you updated all dependencies and you are asking for "auth0-js": "^8.11.2" which I believe is the latest version then I would consider that as the first possibility for the error. You may want to try with previous Auth0.js versions in order to prove this theory. If it proves correct, knowing the exact version at which the problem starts is also helpful to finding the root cause. Meanwhile I can try to reproduce the problem, if you can update the question more information about if it works/fails with previous version that would be great.

6

I updated my app with more dependencies but before i did that I made a copy of the project while it worked. This combination of dependencies is working fine. No error. I just tried it out.

“dependencies”: {
“@angular/animations”: “4.2.5”,
“@angular/common”: “4.2.5”,
“@angular/compiler”: “4.2.5”,
“@angular/compiler-cli”: “4.2.5”,
“@angular/core”: “4.2.5”,
“@angular/forms”: “4.2.5”,
“@angular/http”: “4.2.5”,
“@angular/platform-browser”: “4.2.5”,
“@angular/platform-browser-dynamic”: “4.2.5”,
“@angular/platform-server”: “4.2.5”,
“@angular/router”: “4.2.5”,
“@ngtools/webpack”: “1.5.0”,
“@types/underscore”: “^1.8.3”,
“@types/webpack-env”: “1.13.0”,
“angular2-chartjs”: “^0.3.0”,
“angular2-jwt”: “^0.2.3”,
“angular2-template-loader”: “0.6.2”,
“aspnet-prerendering”: “^3.0.1”,
“aspnet-webpack”: “^2.0.1”,
“auth0-js”: “^8.11.2”,
“awesome-typescript-loader”: “3.2.1”,
“bootstrap”: “3.3.7”,
“chart.js”: “^2.7.0”,
“css”: “2.2.1”,
“css-loader”: “0.28.4”,
“es6-shim”: “0.35.3”,
“event-source-polyfill”: “0.0.9”,
“expose-loader”: “0.7.3”,
“extract-text-webpack-plugin”: “2.1.2”,
“file-loader”: “0.11.2”,
“font-awesome”: “^4.7.0”,
“html-loader”: “0.4.5”,
“isomorphic-fetch”: “2.2.1”,
“jquery”: “3.2.1”,
“json-loader”: “^0.5.4”,
“ng2-toasty”: “^4.0.3”,
“preboot”: “4.5.2”,
“raven-js”: “^3.17.0”,
“raw-loader”: “0.5.1”,
“reflect-metadata”: “0.1.10”,
“rxjs”: “5.4.2”,
“style-loader”: “0.18.2”,
“superagent”: “^3.6.3”,
“to-string-loader”: “1.1.5”,
“typescript”: “2.4.1”,
“underscore”: “^1.8.3”,
“url-loader”: “0.5.9”,
“webpack”: “2.5.1”,
“webpack-hot-middleware”: “2.18.2”,
“webpack-merge”: “4.1.0”,
“zone.js”: “0.8.12”

7

I seem to be having the same exact problem using Lock v10.24.

When using Lock 10.23 instead, I get a different error: nonce does not match.

8

Hi,

They seem to have fixed my issue because i can login no without any errors.

best

9

Hi,

i have the same pb after update to Angular 5.

What did you do to fix the pb?

10

I thought that they fixed it because i didnt do anything particular… i just continued to work on my app (without logging in)… i did however work at the time on refactoring my routing because i didnt have a routingmodule… but the url is still the same so im afraid i dont have the answer to your question

11

I seem to be having the same exact problem using Lock v10.24.

When using Lock 10.23 instead, I get a different error: nonce does not match.

12

Hi,

They seem to have fixed my issue because i can login no without any errors.

best

13

Hi,

i have the same pb after update to Angular 5.

What did you do to fix the pb?

14

I thought that they fixed it because i didnt do anything particular… i just continued to work on my app (without logging in)… i did however work at the time on refactoring my routing because i didnt have a routingmodule… but the url is still the same so im afraid i dont have the answer to your question

15

We’re seeing this same exception. I can reliably reproduce it by starting the auth flow in Firefox, switching to Chrome to finish it. This makes sense, since chrome does not have the correct state token. The problem for us is that it happens intermittently using the same browser/tab/session all the way through.

@jmangelo I have an open support ticket with a ton more detail if you’re able to take a look. It does contain some sensitive things (pieces of our code). I can scrub it and post it here if that’s useful.

16

I am using:
lock.js 10.24.2 (latest 10 version)
auth0.js 8.10.1
angular-lock 2.0.3 (latest)
angular-jwt 0.1.9 (latest)

When I move auth0.js to any version on or after 8.11.x (even the 9.x) I get this error.
lock then requires me to click the login button twice to login and depending on the version of lock, I will get the red message saying STATE MISMATCH etc…

This is for a angularsjs (version 1) app. A regression is definitely introduced between 8.10.1 and 8.11.0.

17

I’m also getting this error with Auth0 Lock.js 11.0.1. I’m using Angular 5.1.1, with angular2-jwt 0.2.3 (latest version). It was not an issue with Lock.js 10.15.1

18

I faced the same issue but for me the issue was only when I used Chrome. It worked fine in other browsers. So clearing the cookies and cache solved it.
I am also using Angular 5.

1 Like
19

This issue happened to me because I was running parseHash() several times.

I noticed after a couple of minutes diving in the auth0.js source code this function that is called when trying to parse the hash:

	TransactionManager.prototype.getStoredTransaction = function(state) {
	  var transactionData;
	
	  transactionData = storage.getItem(this.namespace + state);
      //this line is  the issue
      storage.removeItem(this.namespace + state);
	  return transactionData;
	};

First time it runs everything is fine, second time the storage item doesn’t exist anymore so the state in the transaction manager will always be null.
Not sure it’s a good practice to delete something persistant in a getter… I am pretty sure getters should always be idempotent…
I think you should complete your API with a synchronous and idempotent way to parse the Hash like before.

20

For me, this issue goes away if I don’t set the state, so it seems like that “state” property is used by Lock.js~11, so it can no longer be used for a callback URL (for example). As long as I don’t set the “state” property on initializing lock, authentication works.