Jasonette / JASONETTE-iOS

📡 Native App over HTTP, on iOS
https://www.jasonette.com
MIT License
5.27k stars 352 forks source link

$session.set works for $href urls but not $network.request #309

Closed darenr closed 6 years ago

darenr commented 6 years ago

I use $session.set to set two headers. Whenever my app requests a view using href (tabs, main screen etc) the headers always contain my logged in session headers. However, recently this stopped working. Sometime in the past few weeks. If I $network.request POST to the same domain the session headers are not being sent.

gliechtenstein commented 6 years ago

I just tried this example https://sessionjason.herokuapp.com/posts.json and looks like it's correctly setting the header and therefore working correctly.

Can you try that example and see if that works?

darenr commented 6 years ago

One difference I'm not including the https in my domain. In this app you're doing the same things that work for me, where I'm finding the headers are not being sent is when I make a post using $network.request. If you add a button in one of the posts in the example that makes a call back to the same domain but using $network.request it should show the same thing I'm seeing. I hope this makes sense!

darenr commented 6 years ago

I just tried changing to the fully qualified http://... for the domain and cleared session and tried again and still have the same problem. (latest develop build as of tonight) - and I really appreciate you looking into this, especially on a Friday night!

gliechtenstein commented 6 years ago

I do make a POST $network.request in the example. Maybe I didn't understand what you're saying.

Are you saying this fails when the protocol part is not included? Or happens anytime you make a "method": "post" $network.request? The example I shared makes both GET and POST requests with sessions.

darenr commented 6 years ago

I tried the json you sent and wasn't able to sign up, I kept getting an error saying I need to enter both email + password (which I did), but regardless, the json that I see does a network.request on signup/signin and on success sets the session headers (as I do), then it redirects (via replace) to the list of posts which then sends up those headers (because you're logged in). What I'm doing is exactly that, but I then have a button in the logged in view with an action that calls an API, so it uses the network.request with a post. This post when it gets to my server (heroku) is missing the headers. The view works fine, but not api calls via network.request. You can try my app if you want http://kadist-ios.herokuapp.com/kmap_main, create an account, then select any news article and click the little up array which pops up a menu of actions, you can call "Like Article" and it will issue the network.request with a post and you'll see the headers not getting sent. Hopefully!

gliechtenstein commented 6 years ago

Thanks for finding this, it was a bug. I did a huge refactor on $network.request recently and this bug snuck in while refactoring. This should fix it.

darenr commented 6 years ago

excellent thank you - I'm just glad you were able to also reproduce. None of my tests caught this. It's exciting to see some of the things coming, I've been following the agent commits too.

cpg commented 6 years ago

I was having an issue that looked similar to this, but this fix does not seem to help.

Does a $session.set reset all session headers?

I wanted to use two headers and I am finding that setting one header appears to obliterate the other.

In my app, a user can have access to two areas (one with a "standard" login with user/pw) and the other with a PIN. I used one session.set header "user_credentials" with one login and another header "admin_credentials" with the other.

Individual logins work fine. logging in the two breaks the headers of the one already logged in. i.e. the "first" header is not sent once the second is set.

Was that on purpose or is that a bug?

cpg commented 6 years ago

Confirmed -- all prior session headers are reset (deleted) upon setting of a separate header.

I am not sure if there is a reason for that, but it would seem unnecessary in general (apps may want to add other headers as the user progresses in the app). Akin to cookies. Except if one app wants to use cookies instead to leverage this, the app has to use html, not json (in so far as I understand the cookie implementation).