{"code":209,"error":"invalid session token"} on v2.2.15 #2255

manishsangwan · 2016-07-12T09:13:39Z

I upgraded parse-server from v2.2.7 to v2.2.15. I started getting {"code":209,"error":"invalid session token"} for all the users who had logged in 2-3 days earlier. when i reverted back to v2.2.7. things started working again. is there an issue with v2.2.15

flovilmart · 2016-07-12T11:30:25Z

Can you run with VERBOSE=1 and provide the logs you see with 2.2.15?

nirco123 · 2016-07-12T12:28:07Z

same here, had to downgrade back to 2.2.3

flovilmart · 2016-07-12T12:35:59Z

@nirco123 can you provide the server logs when running with VERBOSE=1?

We've added a more aggressive checking on invalid session tokens, so whenever a session token is provided, if it's invalid, you'll have that error. The logs may help us understand what's the issue

manishsangwan · 2016-07-13T07:23:25Z

@flovilmart I was getting 400 on GET /parse/classes/_Role. Server log has lot of info.What part of the server log do you need?

flovilmart · 2016-07-13T11:49:48Z

I would need the logs related to that call, the ones resulting in an invalid session token error

manishsangwan · 2016-07-15T05:47:53Z

this is the response i get on console

2016-07-15 05:36 +00:00: GET /parse/classes/_Role 400 8.506 ms - 44
2016-07-15 05:36 +00:00: GET /parse/classes/_Role 400 9.485 ms - 44
2016-07-15 05:36 +00:00: GET /parse/classes/_Role 400 8.124 ms - 44
2016-07-15 05:36 +00:00: GET /parse/classes/_Role 400 9.380 ms - 44
2016-07-15 05:36 +00:00: GET /parse/classes/_Role 400 10.750 ms - 44
2016-07-15 05:36 +00:00: GET /parse/classes/_Role 400 8.252 ms - 44
2016-07-15 05:36 +00:00: GET /parse/classes/_Role 400 7.606 ms - 44
2016-07-15 05:36 +00:00: GET /parse/classes/_Role 400 8.787 ms - 44
2016-07-15 05:36 +00:00: GET /parse/classes/_Role 400 8.449 ms - 44
2016-07-15 05:36 +00:00: GET /parse/classes/_Role 400 8.000 ms - 44
2016-07-15 05:36 +00:00: GET /parse/classes/_Role 400 7.608 ms - 44
2016-07-15 05:36 +00:00: GET /parse/classes/_Role 400 8.991 ms - 44
2016-07-15 05:36 +00:00: GET /parse/classes/_Role 400 32.211 ms - 44

and no vebose info but if i create a fresh session i get

2016-07-15 05:38 +00:00: verbose: GET /parse/classes/_Role { host: 'myproject.com',
  'x-scheme': 'http',
  'x-real-ip': '172.31.34.126',
  'x-forwarded-for': '103.212.146.168, 172.31.34.126',
  connection: 'close',
  'content-length': '309',
  accept: '*/*',
  'accept-encoding': 'gzip, deflate, br',
  'accept-language': 'en-US,en;q=0.8,hi;q=0.6',
  'content-type': 'text/plain',
  origin: 'https://myproject.com',
  referer: 'https://myproject.com/',
  'user-agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36',
  'x-forwarded-port': '443',
  'x-forwarded-proto': 'https' } {
  "where": {
    "objectId": "xnA9K8oVPR"
  }
}
2016-07-15 05:38 +00:00: verbose: {
  "response": {
    "results": [
      {
        "objectId": "xnA9K8oVPR",
        "name": "ETVzPMxUQUYMpPEOWFAr",
        "updatedAt": "2016-07-15T05:05:19.938Z",
        "createdAt": "2016-06-21T13:29:08.240Z",
        "companyWorkOrderCount": 26,
        "companyName": " sector 4",
        "companyID": {
          "__type": "Pointer",
          "className": "Company",
          "objectId": "Br4aqkP1mk"
        },
        "currencyDictionary": {
          "name": "United States dollar",
          "code": "USD",
          "symbol": "$"
        },
        "users": {
          "__type": "Relation",
          "className": "_User"
        },
        "roles": {
          "__type": "Relation",
          "className": "_Role"
        },
        "ACL": {
          "*": {
            "read": true,
            "write": true
          }
        }
      }
    ]
  }
}
2016-07-15 05:38 +00:00: GET /parse/classes/_Role 200 85.545 ms - 497

and when i go back to even v2.2.14 older session works nicely.

flovilmart · 2016-07-16T04:31:26Z

Can you try with 2.2.16? Again, with verbose logs of the error?

manishsangwan · 2016-07-18T05:51:33Z

I still get

2016-07-18 05:50 +00:00: GET /parse/classes/_Role 400 8.831 ms - 44
2016-07-18 05:50 +00:00: GET /parse/classes/_Role 400 10.234 ms - 44
2016-07-18 05:50 +00:00: GET /parse/classes/_Role 400 9.779 ms - 44
2016-07-18 05:50 +00:00: GET /parse/classes/_Role 400 12.024 ms - 44
2016-07-18 05:50 +00:00: GET /parse/classes/_Role 400 10.249 ms - 44
2016-07-18 05:50 +00:00: GET /parse/classes/_Role 400 9.973 ms - 44
2016-07-18 05:50 +00:00: GET /parse/classes/_Role 400 8.399 ms - 44
2016-07-18 05:50 +00:00: GET /parse/classes/_Role 400 25.563 ms - 44
2016-07-18 05:50 +00:00: GET /parse/classes/_Role 400 9.550 ms - 44
2016-07-18 05:50 +00:00: GET /parse/classes/_Role 400 10.145 ms - 44
2016-07-18 05:50 +00:00: GET /parse/classes/_Role 400 8.412 ms - 44
2016-07-18 05:50 +00:00: GET /parse/classes/_Role 400 8.841 ms - 44
2016-07-18 05:50 +00:00: GET /parse/classes/_Role 400 9.383 ms - 44

on v2.2.16 and nothing on verbose

ValeryVa · 2016-07-26T06:52:01Z

Still reproduces on 2.2.17. No verbose logs, only the following in console:
at=info method=POST path="/parse/functions/getAllItems" host=mytestapp.herokuapp.com request_id=f0858096-25b1-4a47-82ce-22213aa4c37d fwd="94.39.31.142" dyno=web.1 connect=0ms service=59ms status=400 bytes=535

even for AppOpened web-service

at=info method=POST path="/parse/events/AppOpened" host=mytestapp.herokuapp.com request_id=7d9f7212-41bd-4ea1-ba97-3f9334d6536b fwd="94.39.31.142" dyno=web.1 connect=1ms service=178ms status=400 bytes=535

I'm not sure that it's ok to return 400 (or error code = 209) in response for internal Parse methods which are not under developer's control

TimothyDavidW · 2016-08-12T08:42:10Z

Hi, is there an update on this issue. We have just completed our migration from parse.com to our own instance of parse server and have also experienced {"code":209,"error":"invalid session token"} for many users which forces them to log in again.

This was never an issue on our parse.com instance. We experienced the issue on the latest version of parse (2.2.17) and have now rolled back to 2.2.7 just to be sure we don't experience the issue on our Live environment.

Many Thanks.

chrisfoulds · 2016-09-02T11:36:38Z

and update on this issue ? or shall I just roll back ?

flovilmart · 2016-09-02T12:16:50Z

this is likely because all your users are still using a non revocable session. If that's the case, all ACL based security cant work, as we don't load the user pre 2.2.17. It was a bug that we would let invalid session tokens go through the requests as we don't support those legacy tokens.

I'm working on the upgrade method in order to make the revocable sessions seemlessly upgrade to revocable session when calling the upgradeToRevocableSession Method in the client SDK's

chrisfoulds · 2016-09-02T12:45:17Z

So I have a user that has upgraded to a revocable session on previous sdk - session token is

{
    "_id": "G56zeYQd43",
    "restricted": false,
    "expiresAt": {
        "$date": "2017-09-02T11:29:54.675Z"
    },
    "_acl": {
        "fCg51Odasn": {
            "r": true,
            "w": true
        }
    },
    "_rperm": [
        "fCg51Odasn"
    ],
    "createdWith": {
        "action": "upgrade"
    },
    "_created_at": {
        "$date": "2016-09-02T11:29:54.711Z"
    },
    "_session_token": "r:BUv2pjaRzirhhdIFZcgoSWQEP",
    "installationId": "7df5cd59-e99d-460f-8ba3-7c6a0e4129a0",
    "_p_user": "_User$fCg51Odasn",
    "_updated_at": {
        "$date": "2016-09-02T11:29:54.711Z"
    },
    "_wperm": [
        "fCg51Odasn"
    ]
}

When that user upgrades the app to pointing straight at the new server I get 209 errors.

If on that same user I do a full login on the old client I get the following session.

{
    "_id": "FbXPAbBGAV",
    "_session_token": "r:3ed2469e6b7d4c4b84d7be2ab1bec7c9",
    "_p_user": "_User$fCg51Odasn",
    "createdWith": {
        "action": "login",
        "authProvider": "password"
    },
    "restricted": false,
    "expiresAt": {
        "$date": "2017-09-02T11:32:02.605Z"
    },
    "installationId": "7df5cd59-e99d-460f-8ba3-7c6a0e4129a0",
    "_created_at": {
        "$date": "2016-09-02T11:32:02.606Z"
    },
    "_updated_at": {
        "$date": "2016-09-02T11:32:02.606Z"
    }
}

Then when I flip that user to pointing straight at the new server all is good.

It's like the upgrade tokens are not valid ?!?!

flovilmart · 2016-09-02T13:06:19Z

t's like the upgrade tokens are not valid ?!?!

they are valid:

Then when I flip that user to pointing straight at the new server all is good.

Upgrading the session token is unavailable on parse-server, but if you upgrade your users on api.parse.com then flip to parse-server that should be all good.

The updgradeSessionToken endpoint is not implemented and the middlewares that verify the session token gets hit before we can send a 404. This is probably why you're seing that behaviour.

Like I said, I plan to ship in 2.2.19 the updgradeSessionToekn method on parse-server you you can seamlessly upgrade the users.

flavionegrao · 2016-09-02T13:27:35Z

Hi @flovilmart, is there a chance that there's something else going weird here.?

I run a cluster of 3x parse servers (2.2.17) pointing towards the same mongodb cluster.
Suddenly one parse-server starts to present 209 errors while the others are ok for the same user with the same request:

parse-server_1 | error:  code=209, message=invalid session token
parse-server_1 | error: beforeSave failed for Order for user WUuw1onCFJ:
parse-server_1 |   Input: {"salesPerson":{"__type":"Pointer","className":"_User","objectId":"WUuw1onCFJ"},"customer":{"__type":"Pointer","className":"Customer","objectId":"mrNGXnSdAn"},
parse-server_1 |   Error: {"code":141,"message":{"code":209,"message":"invalid session token"}} className=Order, triggerType=beforeSave, code=141, code=209, message=invalid session token, user=WUuw1onCFJ
parse-server_1 | error: Error generating response. ParseError {
parse-server_1 |   code: 141,
parse-server_1 |   message: ParseError { code: 209, message: 'invalid session token' } } code=141, code=209, message=invalid session token

I restart the instance and the problem vanishes, would you tell me how to debug it and try to figure out the problem?

chrisfoulds · 2016-09-02T13:28:40Z

Upgrading the session token is unavailable on parse-server, but if you upgrade your users on api.parse.com then flip to parse-server that should be all good.

That is what I am doing in both scenarios.
On scenario A the user is logged in with a legacy id, I then perform an upgrade against api,.parse.com and get a session token (the first one I gave). I then upgrade that user to a new version of the app that points at my parse server. I get error 209. (See server log 1 below)
On scenario B the user is not logged in at all. I then get the user to login fresh against api.parse.com to get a session token.
I then upgrade that user to a new version of the app that points at my parse server - it works.
(See server log 2 below)

These are the logs from my two scenarios on the server

2016-09-02T13:24:22.880130+00:00 heroku[router]: at=info method=GET path="/parse/classes/_User/fCg51Odasn" host=xxxxyyyy.herokuapp.com request_id=b2c7cec9-ca23-4b2b-9893-f57f9cbe8d6f fwd="86.145.15.6" dyno=web.1 connect=2ms service=29ms status=400 bytes=572

2016-09-02T13:26:48.201705+00:00 heroku[router]: at=info method=GET path="/parse/classes/_User/fCg51Odasn" host=xxxxyyyy.herokuapp.com request_id=9bc987d0-0464-44b7-98fa-43945f57eaa1 fwd="86.145.15.6" dyno=web.1 connect=1ms service=31ms status=200 bytes=1341

Hence my view that upgrade tokens are not working as I can't see what else I am doing wrong here ?

flovilmart · 2016-09-02T13:34:36Z

Uhm.... that's very very odd, Do you have the full server logs, with request headers?

flavionegrao · 2016-09-02T13:40:36Z

No, I don’t, they are in my production env. I have just the ‘info’ level logged.
One more thing, all parse-servers run the same docker image, I would guess something is triggering a inconsistent status somehow.
Cheers.

On 2 de set de 2016, at 10:34 AM, Florent Vilmart [email protected] wrote:

Uhm.... that's very very odd, Do you have the full server logs, with request headers?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #2255 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABhfNAqtaOAIQELtU_-kdUtKU7--t-H9ks5qmCYDgaJpZM4JKMJF.

flovilmart · 2016-09-02T13:43:23Z

Uhm... I'm not sure, do the request hit the same server or different ones? Does the newly acquired session token starts with r:

flavionegrao · 2016-09-02T13:48:49Z

I am behind a AWS ELB instance, sometimes hit the same, depends on the server load.
But when the user tries several times and it hits other server or I manually restart the problematic one, it goes through.

On 2 de set de 2016, at 10:43 AM, Florent Vilmart [email protected] wrote:

Uhm... I'm not sure, do the request hit the same server or different ones?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #2255 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABhfNIOS-O3AeGgceJelgzvjY3C3KyWrks5qmCgSgaJpZM4JKMJF.

flovilmart · 2016-09-02T14:08:56Z

We do have caching on the user objects per sessionToken but I don't see how it can interfere as when refreshing the session token, the previous entry become unaccessible...

chrisfoulds · 2016-09-02T16:20:20Z

@flovilmart do you require any more info from me as I have tried with multiple users and they all get error 400 if they are on an upgrade token

flovilmart · 2016-09-02T17:03:03Z

Anything you can provide may help. Upgraded token should work fine. Mostly we need the 'X-Parse-Session-Token', if you post it, obfuscate it. Do they have a 'r:' starting the string?

chrisfoulds · 2016-09-02T17:16:04Z

In my previous comment I gave the session tokens for both scenarios (see earlier) both have r: starting the string

flovilmart · 2016-09-02T17:34:55Z

Uhh right sorry. If you manage to reproduce it again (1st case, session token is not usable), can you check in the DB if the _Session records match in structure i.e.: the sessionToken stored key is the same as one with a successful login?

flovilmart · 2016-09-02T19:25:39Z

@chrisfoulds see #2646 maybe that will help. Do you want to try it as you have a very nice way to reproduce your issue?

chrisfoulds · 2016-09-02T21:03:26Z

@flovilmart getting a bit late in the day overhere but will certainly try it out over the weekend and let you know how it goes.

I did check the records and they all seem to line up between the servers. I basically have my app with a flipswitch in it now, so after it fails if flip the switch and restart the app to go back to api.parse.com I get straight back in, it's just using that revocable upgrade session on parse-server , yet a login one still works fine. Tried a server rebuild and numerous restarts and keep getting the same.

Anyway will try it over the weekend and feedback, I am hopeful as if the upgrade takes places on my server surely it's going to like the output!

flovilmart · 2016-09-02T22:46:49Z

Awesome, thanks for trying it out. Check out the wiki for running Parse-server from a branch, that's a bit complex as the default npm way won't work. Need to submodule, checkout branch, npm link.

dwby · 2017-01-25T00:10:27Z

@flovilmart fixed it on my end. Turns out it was a client issue. Apols

flovilmart · 2017-01-25T01:06:56Z

No need to apologize!

xavierbabu · 2017-01-28T01:07:59Z

@dwby Could you please what did you fix. We face similar issue in 2.2.24

maximeloizeau · 2017-01-31T18:04:54Z

I am also getting this issue. I have 3 instances running and it happened on one of them, the others responded correctly.

Strange thing is also that I get this response from a cloud function that doesn't need any authentication (and I do not provide any token in the headers). Also a client issue doesn't seem probable since I did some requests from Postman and got the error.

I would love to know what the client issue was still, @dwby.

If anyone of you has any idea where to start to investigate this issue, thank you!

EDIT: not that a server restart always fixes it. Since you were talking about caching, I will try to have a look there.
EDIT2: I did not migrate from Parse.

dwby · 2017-01-31T18:36:01Z

@maximeloizeau @xavierbabu sorry about the late reply. The client issue had nothing to do with Parse Server. It was just an issue with an incorrect string. One of my calls to Parse relies on a stored date value which was not present due to the incorrect string.

maximeloizeau · 2017-02-02T13:29:11Z

@xavierbabu

I found the cause of that error, see the referenced issue #3471. Do you think this may be the same problem for you?

RafaRuiz · 2017-02-25T19:52:11Z

This problem has always happened to me.
I'm handling requests to the Cloud without SessionToken (open free endpoint) and even thought not sending any SessionToken, I get the 209.

The only solution to fix this is restarting the server, and it works like charm.
@flovilmart given this, would you need me to log anything for you to cover this?

flovilmart · 2017-02-25T20:24:05Z

Any additional information would be welcome. I'm not sure why restarting the server would fix the issue, perhaps a problem with some caching that we do on users and roles

maximeloizeau · 2017-02-25T20:42:24Z

@RafaRuiz, do you use Parse.User.logIn or Parse.User.become anywhere in your cloud code?

Not using those at all fixed it for us.

flavionegrao · 2017-02-26T11:31:03Z

@maximeliozeau all yours parse instances are pointing to a redis instance?

maximeloizeau · 2017-02-26T11:45:40Z

No, we use the default in-memory cache adapter. If you use the two functions I mentioned, I don't think it matters because there's a caching done at the Parse SDK level on the server which causes problems. Florent indicated that you are not supposed to use this two functions on the server at all.

…

On Sun, 26 Feb 2017, 11:31 Flavio Torres, ***@***.***> wrote: @maximeliozeau all yours parse instances are pointing to a redis instance? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2255 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABbshBDtreNk7lscah2VIf1-RV09U8TRks5rgWKBgaJpZM4JKMJF> .

RafaRuiz · 2017-02-26T15:27:12Z

@maximeloizeau Yes, I use Parse.User.logIn in JS, iOS and Android.

@maximeloizeau @flovilmart One more hint:

These are the two scenarios it happened:

Already logged user in iOS SDK tried to call and endpoint in the Cloud. Got 209. Even though the sessionToken wasn't expired, it didn't allow to call that endpoint. The endpoint is not saving or doing anything except GET. CLP were OK. It was happening with some endpoints, and not with other endpoints, but there's no relation (I can post the code if you want to).
After logging out and in again it was solved.
Already logged user in JS SDK tried to call the same endpoints, got 209, and logged out. In our website we have some features that we show without sending sessionToken (so the endpoint is free through any curl call). Even though the user was logged out and I cleaned sessionStorage and localStorage, some of calls were returning 209 and some others not.

To help debugging this, is there any way to see the line that threw the error?

RafaRuiz · 2017-02-26T17:22:11Z

Ok, I started debugging the problem.

My version was 2.3.2.

It's happening at src/Auth.js line 60.

It seems it was asking to Auth with an existing installationId from middlewares.js.

I've installed 2.3.5 and trying to reproduce by the same steps I've done in 2.3.2 and it's not happening. I will update if it happens again.

flovilmart · 2017-02-26T18:58:10Z

It's happening at src/Auth.js line 60.

So that means the sessionToken isn't found in the _Session table. Or that multiple session match for the same sessionToken which is very odd.

mman · 2017-03-21T12:22:15Z

I have started getting invalid session token code=209, message=invalid session token today after upgrading to 2.3.7. Looking at Auth.js line 60 and investigating I have found out that there are actually two different session ids for the same user and same installation-id.

Looking at their timestamps they are actually pretty weird as they are _created_at few milliseconds apart...

Not sure whether my investigation is correct but I'm pasting the mongo query with the results below for you to asses:

rs0:PRIMARY> db.getCollection('_Session').find({"_p_user":"_User$HngzyE3Clx"})
{ "_id" : "4sQEyDhudw", "_session_token" : "r:e7500d9da1f7ea868e0e21c14b9cd83e", "_p_user" : "_User$HngzyE3Clx", "createdWith" : { "action" : "login", "authProvider" : "password" }, "restricted" : false, "expiresAt" : ISODate("2018-01-03T09:29:19.181Z"), "installationId" : "2b907a0c-26eb-4f19-bd6b-8dd7a734ec0c", "_created_at" : ISODate("2017-01-03T09:29:19.182Z"), "_updated_at" : ISODate("2017-01-03T09:29:19.182Z") }
{ "_id" : "Hn4AKvsUHi", "_session_token" : "r:e5e605f07e51c57de3e4601d3245aa34", "_p_user" : "_User$HngzyE3Clx", "createdWith" : { "action" : "login", "authProvider" : "password" }, "restricted" : false, "expiresAt" : ISODate("2018-01-03T09:29:19.201Z"), "installationId" : "2b907a0c-26eb-4f19-bd6b-8dd7a734ec0c", "_created_at" : ISODate("2017-01-03T09:29:19.202Z"), "_updated_at" : ISODate("2017-01-03T09:29:19.202Z") }
{ "_id" : "NwZxUuYmZt", "_session_token" : "r:3f9876c47dd44257afafed29c9203fd9", "_p_user" : "_User$HngzyE3Clx", "createdWith" : { "action" : "login", "authProvider" : "password" }, "restricted" : false, "expiresAt" : ISODate("2018-01-04T10:35:34.458Z"), "installationId" : "710680df-6519-42be-a675-d0dab62cdee5", "_created_at" : ISODate("2017-01-04T10:35:34.458Z"), "_updated_at" : ISODate("2017-01-04T10:35:34.458Z") }
{ "_id" : "SbwP8G7jDQ", "_session_token" : "r:f8b307985b8c4ebed1330202aa30594a", "_p_user" : "_User$HngzyE3Clx", "createdWith" : { "action" : "login", "authProvider" : "password" }, "restricted" : false, "expiresAt" : ISODate("2018-01-04T10:35:34.453Z"), "installationId" : "710680df-6519-42be-a675-d0dab62cdee5", "_created_at" : ISODate("2017-01-04T10:35:34.453Z"), "_updated_at" : ISODate("2017-01-04T10:35:34.453Z") }
{ "_id" : "BVMouretHK", "_session_token" : "r:25d3e52c371386b56e96d0f9b839c287", "_p_user" : "_User$HngzyE3Clx", "createdWith" : { "action" : "login", "authProvider" : "password" }, "restricted" : false, "expiresAt" : ISODate("2018-01-05T01:30:30.838Z"), "installationId" : "bcf5b055-3b1c-4dc2-a405-5e04a5a1c3ad", "_created_at" : ISODate("2017-01-05T01:30:30.838Z"), "_updated_at" : ISODate("2017-01-05T01:30:30.838Z") }
{ "_id" : "iHVJWkOFsV", "_session_token" : "r:97ee17db8bc95ad6b657abb84aec39cb", "_p_user" : "_User$HngzyE3Clx", "createdWith" : { "action" : "login", "authProvider" : "password" }, "restricted" : false, "expiresAt" : ISODate("2018-01-05T01:30:30.864Z"), "installationId" : "bcf5b055-3b1c-4dc2-a405-5e04a5a1c3ad", "_created_at" : ISODate("2017-01-05T01:30:30.864Z"), "_updated_at" : ISODate("2017-01-05T01:30:30.864Z") }
{ "_id" : "SxZux6gBcs", "_session_token" : "r:748b0629fad3537c64bdff4f16eb66b6", "_p_user" : "_User$HngzyE3Clx", "createdWith" : { "action" : "signup", "authProvider" : "password" }, "restricted" : false, "installationId" : "c48adf7f-7b67-4a68-a7b0-91422c3141d2", "expiresAt" : ISODate("2018-01-03T09:25:13.906Z"), "_created_at" : ISODate("2017-01-03T09:25:13.906Z"), "_updated_at" : ISODate("2017-01-03T09:25:13.906Z") }
{ "_id" : "wVY87z45Rd", "_session_token" : "r:1aaa34b479dbc40a98b92895fde3c210", "_p_user" : "_User$HngzyE3Clx", "createdWith" : { "action" : "login", "authProvider" : "password" }, "restricted" : false, "expiresAt" : ISODate("2018-02-23T13:12:54.912Z"), "installationId" : "ee8b543c-3108-43ef-85e8-383614581082", "_created_at" : ISODate("2017-02-23T13:12:54.912Z"), "_updated_at" : ISODate("2017-02-23T13:12:54.912Z") }
{ "_id" : "YQ8jGPOkdy", "_session_token" : "r:501c602c40834ef82637300847ce0d3d", "_p_user" : "_User$HngzyE3Clx", "createdWith" : { "action" : "login", "authProvider" : "password" }, "restricted" : false, "expiresAt" : ISODate("2018-02-23T13:12:55.494Z"), "installationId" : "ee8b543c-3108-43ef-85e8-383614581082", "_created_at" : ISODate("2017-02-23T13:12:55.494Z"), "_updated_at" : ISODate("2017-02-23T13:12:55.494Z") }

OpConTech · 2017-04-05T22:41:31Z

My apologies to the group if this is a dumb question but is there an example somewhere of how to use upgradeToRevocableSession in an iOS client?

I can't seem to find anything in the documentation or on StackOverflow.

flovilmart · 2017-04-07T02:55:13Z

@OpConTech not sure if you should use upgradeToRevocableSession now that parse.com is down. parse-server only use revocable sessions.

flovilmart · 2017-04-07T02:55:49Z

@mman you should look into your client code a it seems you're sending out multiple login requests concurrently.

flovilmart · 2017-04-07T03:12:37Z

@mman I'm investigating now, and we apply a limit to the query to get the 1st object, so those concurrent request should be OK. Do you run multiple instances without a distributed cache like REDIS?

mman · 2017-04-07T08:23:03Z

@flovilmart Yes I have nginx doing SSL termination and load balancing to multiple parse instances that are then talking to the mongo cluster. But in my case it was simply a logic bug that the two login requests are sent immediately after each other thus creating two session ids. Limiting the output of the query to accept either session id as valid would work great for my case.

flovilmart · 2017-04-07T11:41:52Z

That's the thing, the output is already limited as it gets the 1st result only.
I started to debug this and I can't reproduce this issue locally.

I have 1 sessions created per login call, but subsequent API calls don't fail.

I'll investigate further

mman · 2017-04-07T13:03:31Z

If you want to reproduce this you have to call PFUser.loginInBackground twice with the same credentials. I'm using it over the internet.

I think the goal is to trigger two parallel mongo _Session.create operations for the same installationId

I'm not sure but perhaps calling it twice over localhost parse-server to the localhost mongo will make the first _Session.create so fast that the other will not create new session?

mman · 2017-04-07T13:05:48Z

@flovilmart To clarify: the second login will not fail. The second login is supposed to create new session row for the same instllationId. What fails is any further API call that verifies the sessionId and finds two rows for the same installationId.

flovilmart · 2017-04-07T13:11:23Z

Yeah but it should never return 2 rows, as we apply limit: 1 to the query.
During my tests, I call 3 times the login method, effectively creating 3 sessions, and everything was A-OK, able to make calls with any of the 3 session tokens. What's worrisome is that I can't pinpoint if:

more than 1 row is returned (limit not correctly processed)
if no results is returned.

As you can see in your DB, all the sessions are stored, and the code finds the session by sessionToken (

parse-server/src/Auth.js

Line 56 in ca286b7

    
           var query = new RestQuery(config, master(config), '_Session', {sessionToken}, restOptions);

)

mman · 2017-04-07T13:36:42Z

Do I understand you right that you are trying to say that the existing code at

parse-server/src/Auth.js

Line 56 in ca286b7

    
           var query = new RestQuery(config, master(config), '_Session', {sessionToken}, restOptions);

must already return just one row because it's effectively limited by the {sessionToken} criteria?

Correct?

flovilmart · 2017-04-07T13:50:51Z

By the limit: 1 provided:

var restOptions = {
      limit: 1,
      include: 'user'
    };

mman · 2017-04-09T16:53:35Z

Looking at the condition that leads to throwing the 'invalid session' error again:

      if (results.length !== 1 || !results[0]['user']) {

I'm really puzzled, because the other part !results[0]['user'] really is not failing for my records listed above... so I assumed it must be the first condition, so all evidence points towards the direction that limit: 1 in restOptions might be ignored? Where is the RestQuery coming from? It's a parse-server code?

flovilmart · 2017-04-09T18:25:18Z

yep it's part of parse-server code, that's the main class for handling all queries, heavily tested... I'm baffled too.

flovilmart self-assigned this Jul 16, 2016

flovilmart mentioned this issue Sep 2, 2016

Adds endpoint for non-revocable session token upgrade #2646

Merged

maximeloizeau mentioned this issue Feb 2, 2017

currentUser caching in Parse-JS-SDK #3471

Closed

mman mentioned this issue Mar 21, 2017

invalid session token code=209, message=invalid session token on v2.3.7 #3655

Closed

{"code":209,"error":"invalid session token"} on v2.2.15 #2255

{"code":209,"error":"invalid session token"} on v2.2.15 #2255

Comments

manishsangwan commented Jul 12, 2016 • edited Loading

flovilmart commented Jul 12, 2016

nirco123 commented Jul 12, 2016

flovilmart commented Jul 12, 2016 • edited Loading

manishsangwan commented Jul 13, 2016 • edited Loading

flovilmart commented Jul 13, 2016 • edited Loading

manishsangwan commented Jul 15, 2016

flovilmart commented Jul 16, 2016

manishsangwan commented Jul 18, 2016

ValeryVa commented Jul 26, 2016 • edited Loading

TimothyDavidW commented Aug 12, 2016

chrisfoulds commented Sep 2, 2016

flovilmart commented Sep 2, 2016

chrisfoulds commented Sep 2, 2016

flovilmart commented Sep 2, 2016

flavionegrao commented Sep 2, 2016

chrisfoulds commented Sep 2, 2016 • edited Loading

flovilmart commented Sep 2, 2016

flavionegrao commented Sep 2, 2016

flovilmart commented Sep 2, 2016 • edited Loading

flavionegrao commented Sep 2, 2016

flovilmart commented Sep 2, 2016 • edited Loading

chrisfoulds commented Sep 2, 2016

flovilmart commented Sep 2, 2016

chrisfoulds commented Sep 2, 2016

flovilmart commented Sep 2, 2016

flovilmart commented Sep 2, 2016

chrisfoulds commented Sep 2, 2016

flovilmart commented Sep 2, 2016

dwby commented Jan 25, 2017

flovilmart commented Jan 25, 2017

xavierbabu commented Jan 28, 2017

maximeloizeau commented Jan 31, 2017 • edited Loading

dwby commented Jan 31, 2017

maximeloizeau commented Feb 2, 2017

RafaRuiz commented Feb 25, 2017

flovilmart commented Feb 25, 2017

maximeloizeau commented Feb 25, 2017 • edited Loading

flavionegrao commented Feb 26, 2017

maximeloizeau commented Feb 26, 2017 via email

RafaRuiz commented Feb 26, 2017 • edited Loading

RafaRuiz commented Feb 26, 2017

flovilmart commented Feb 26, 2017

mman commented Mar 21, 2017

OpConTech commented Apr 5, 2017

flovilmart commented Apr 7, 2017

flovilmart commented Apr 7, 2017

flovilmart commented Apr 7, 2017

mman commented Apr 7, 2017 • edited Loading

flovilmart commented Apr 7, 2017

mman commented Apr 7, 2017

mman commented Apr 7, 2017

flovilmart commented Apr 7, 2017

mman commented Apr 7, 2017

flovilmart commented Apr 7, 2017 • edited Loading

mman commented Apr 9, 2017

flovilmart commented Apr 9, 2017

manishsangwan commented Jul 12, 2016 •

edited

Loading

flovilmart commented Jul 12, 2016 •

edited

Loading

manishsangwan commented Jul 13, 2016 •

edited

Loading

flovilmart commented Jul 13, 2016 •

edited

Loading

ValeryVa commented Jul 26, 2016 •

edited

Loading

chrisfoulds commented Sep 2, 2016 •

edited

Loading

flovilmart commented Sep 2, 2016 •

edited

Loading

flovilmart commented Sep 2, 2016 •

edited

Loading

maximeloizeau commented Jan 31, 2017 •

edited

Loading

maximeloizeau commented Feb 25, 2017 •

edited

Loading

RafaRuiz commented Feb 26, 2017 •

edited

Loading

mman commented Apr 7, 2017 •

edited

Loading

flovilmart commented Apr 7, 2017 •

edited

Loading