Session lost when created a new one (for a different user)

REST API
1

Hi,
Currently, when I create a session for a user, and then execute a get from DB with that session_id (lets call it session_id_1) it works. But if inmediately after I create another session for a different user, getting a different session_id, and then I try to repeat the get from DB with the session_id_1 it looks it lost the session.

The headers I’m using in my test are: For the login,
X-DreamFactory-Application-Name

For the get from DB,
X-DreamFactory-Application-Name
X-DreamFactory-Session-Token

The body of login is:
{“email”:“xx@xx.xxx”,“password”:“xxxx”}

I would like to know if it is possible to succesfully authenticate using session_id_1 for the second db get (after second login).

Thanks

2

Hi manu. I’m unable to replicate this issue. Can you provide some more details?
What tool/app/interface are you using to test this?

3

Hi Drew,
I’m getting this behavior in my android app (it is an app based on the ToDo example), and using the hosted DSP. But I could reproduce it with a Chrome extension, as Postman.
I’ve tried to put as much detail as possible, but if you tell me what else might help I’d glad to add it.

Thanks!

4

Thanks manu. I was able to replicate this issue using Postman. Before I was just testing with cURL and didn’t have the issue. I’ll have to look into this and see why it’s happening. Seems like on creating the new session, it’s deactivating the old one, even though its for a different user.

5

Got some clarification from Engineering on this. This is happening due to session cookies being stored in the browser application. If you had separate devices or separate browsers this would not happen, so it’s not an issue for your application in production (your users wouldn’t be sharing a device/browser without logging in and out anyway.)
In DF 2.0 sessions are handled with JWT, so the browser cookie is no longer a limiting factor.

6

Hi Drew,
thanks a lot for the quick reply, that’s great support.
Just to clarify, my Android app has an async feature triggered with an Intent that by (initial) design needs to login and update the DB @ DSP. Ideally, these credentials should not be the ones from the user, that’s why we included that login step in the flow.

I’ll dig on my options here with the cookies in the Android app and I’ll update this thread if I find something interesting.

But again, thanks a lot for the valuable information and guidance towards the underlying issue.

Thanks,
Emmanuel.

7

Hi,
just one more thing. I’m using the hosted DSP. Are you planning to move 2.0 soon?

Thanks
Emmanuel.

8

Yes, the free sandbox environment will be redirected to 2.0 before long. At that time, existing 1.x instances will not be upgraded; but new instances created will be 2.0.