Simplenote login6/16/2023 If we find out why this its happening we'll probably discover why it's failing in this issue. I created a clone of yours with this switch though and it didn't seem to matter.Īt the heart of this issue is the 200 OK instead of the 302 FOUND response. On the other hand, the test OAuth client you created uses Native when I think it should be Web. I'm suspicious that we might have an issue on the server when dealing with that protocol link. When the redirect_uri is the response to the request is a 302 -> expected redirect URL with parameters but when it's simplenote://auth the request returns a 200 with nothing but a cookie. This one does the final redirect, and I found something. I used the "Persist Logs" function in the browser network tab and waited until I was ready to hit "Approve" on the "Hello!" screen. did our OAuth process change? no, but the token request isn't providing a redirect! why not?.we should cancel the request and grab the code from the URL there in that handler. I think we are allowing the existing request to continue along as-is which brings it right back to our registered handler. we might be spinning in a loop because in our registerHttpProtocol( 'simplenote', … ) call we aren't doing anything with the request.in the main app as it uses the default session for the application if none is provided this might help us also track things that are happening in the window vs. the Electron docs are vague but we can create a new session for the BrowserWindow to start fresh with no cookies.the web version and Electron versions should use different mechanisms (web should have auto-expiring token probably, and Electron can store the code) but we're getting lost in the imperative code and interplay with the BrowserWindow. It seems to me like we're probably just confused in this code. the token response type provides a time-limited access token, defaulting to two weeks. there aren't complicated redirect procedures involved. I think that the token response is meant to set the cookie and have that be that. On the other hand, if we simply request request_type=token we get a response back with set-cookie HTTP headers containing the access token, not a redirect. But we're not turning around and making that second request so the authentication never goes through. ![]() ![]() ![]() that SOMECODE is supposed to then be used with a new POST call to which then finally gives us our expected token inside the response as a JSON payload. Since we ask for response_type=code the API call responds with simplenote://auth?code=SOMECODE. the user, token, and state parameters would come from this. !( after some auditing I stumbled upon some oddities.įor one, we request the OAuth token with request_type=code but it looks like we are testing for the redirect URL to be the response from request_type=token. Simplenote://auth?state=app-6ef47a0237be4f999999&user=REDACTED&token=0a2a.7e70&wp_token=17QE.0PMi&new=false`īut SimpleNote can't complete the call-back! ![]() Which receives an HTTP/302 Redirect to the following URI (callback): SimpleNote then calls that redirected URI above: wpcc?code=XXXXXXXXX&state=app-6ef47a0237be4f999999`Īnd sets various cookies related to my account ID and credentials. When I click on the Authorize button, SimpleNote calls the following URI: The debug console shows a bunch of messages though under the Network tab: Removing SimpleNote and re-adding it didn't help.
0 Comments
Leave a Reply. |