I've seen several similar issues reported on here, but none of the solutions or specific setups seem to be quite matching mine.
I have a React client that is calling a backend Framework Web API via apollo, which is setting an http only cookie that I am expecting to be sent back in all subsequent requests. The backend service is configured to accept the client domain as CORS origin and locally as well as when deployed to a test server this is all working fine.
I have now deployed both the client and back end service to separate Azure App Services and the cookie 'appears' to not be getting set on the client.
In the initial response headers I can see the cookie being set in set-cookie, but it is not then included in subsequent requests and does not appear in the applications tab in chrome tools.
My Apollo calls are specifying withCredentials: true
Any idea what the reason for this may be?
Edit.
The response headers coming back from the initial API request are:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://my-app-service.azurewebsites.net
Cache-Control: no-cache
Content-Encoding: gzip
Content-Length: 256
Content-Type: application/json; charset=utf-8
Date: Fri, 29 Oct 2021 12:04:27 GMT
Expires: -1
Pragma: no-cache
Server: Microsoft-IIS/10.0
Set-Cookie: {Cookie-Name}={JWT-Token}; expires=Fri, 29-Oct-2021 12:24:27
GMT; path=/; HttpOnly
Vary: Accept-Encoding
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Related
In my application, the front end (ReactJS using axios, if that matters) makes some API calls to the backend (Node/Express, again if that matters). In all of the responses, server does responds with Access-Control-Allow-Origin:* (This is a test environment, appropriate changes will be made to allow specific origins in production).
In the Chrome Developer Tools Network tab, I observe that for every request say POST /assets , POST /filters, PUT /media etc., a preflighted OPTIONS request is sent. Now I do understand from here, the reason for those and that's fine.
OPTIONS Request Headers
OPTIONS /api/v1/content/bb54fbf52909f78e015f/f91659797e93cba7ae9b/asset/all
HTTP/1.1
Host: XX.X.XX.XXX:5000
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://localhost:3000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Access-Control-Request-Headers: authorization,content-type
Accept: */*
DNT: 1
Referer: http://localhost:3000/main/93f1ced0f15f35024402/assets
Accept-Encoding: gzip, deflate
Accept-Language: en,en-US;q=0.8,mr;q=0.6
Response Headers
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
Vary: Access-Control-Request-Headers
Access-Control-Allow-Headers: authorization,content-type
Date: Sat, 05 Aug 2017 10:09:16 GMT
Connection: keep-alive
My observation is that this is sent for literally every requests, and repetitively i.e. even if the same request is being made again (immediately or otherwise).
My questions are
Is this necessarily a bad thing (i.e. would it cause any performance issues, even minor)?
Why doesn't browser remember the header responses for the same server, same request?
Is there anything I am missing to configure on the front end or backend for making this sticky?
You need to send the Access-Control-Max-Age header to tell the browser that it’s OK to cache your other Access-Control-* headers for that many seconds:
Access-Control-Max-Age: 600
I would like to create a connection pool to a https endpoint where an addition step is performed after creating each https connection in the pool. The step is to make a https call like so:
POST /_session HTTP/1.1
Content-Length: 32
Content-Type: application/x-www-form-urlencoded
Accept: */*
name=YourUserName&password=YourPassword
If successful, in response a cookie is returned, e.g:
200 OK
Cache-Control: must-revalidate
Content-Length: 42
Content-Type: text/plain; charset=UTF-8
Date: Mon, 04 Mar 2013 14:06:11 GMT
server: CouchDB/1.0.2 (Erlang OTP/R14B)
Set-Cookie: AuthSession="a2ltc3RlYmVsOjUxMzRBQTUzOtiY2_IDUIdsTJEVNEjObAbyhrgz"; Expires=Tue, 05 Mar 2013 14:06:11 GMT; Max-Age=86400; Path=/; HttpOnly; Version=1
x-couch-request-id: a638431d
Where would this extra step go? For example, maybe I should extend the _new_conn method?
class CustomHTTPSConnectionPool(HTTPSConnectionPool):
def _new_conn(self):
conn = super(CustomHTTPSConnectionPool, self)._new_conn()
... call '/_session' and save cookie
return conn
Another consideration is that the cookie will expire and should be renewed, ideally before the expiration. I'm just noting it here, that should probably be the subject of a separate question.
(As discussed in the comments)
If you're trying to create your own CustomHTTPSConnectionPool, you're on the right track.
But reading the docs you linked, I don't think you need this? It seems the state is maintained in the cookie rather than the connection, so you just need to do the handshake, get a cookie, and make sure you pass the cookie with each request and you're good to go regardless of connections.
I'm playing with the Google Drive API. I've managed to authenticate successfully and retrieve file listings and other things, but my goal is to write an alternative (if limited) editor for documents held in Google Drive. Unfortunately the downloadUrl referred to in the docs (https://developers.google.com/drive/v2/reference/files) does not exist, only exportLinks. It seems in order to deal with the native formatting of documents in Google Drive, it's necessary to use the realtime API.
Very well, I tried to retrieve the undocumented (but hinted at) realtime resource hinted at by the documentation, found at: https://www.googleapis.com/drive/v2/files/FILEID/realtime -
HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=UTF-8
Date: Tue, 05 Aug 2014 03:02:51 GMT
Expires: Tue, 05 Aug 2014 03:02:51 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Alternate-Protocol: 443:quic
Transfer-Encoding: chunked
{
"error": {
"errors": [
{
"domain": "global",
"reason": "lockedDomainCreationFailure",
"message": "The OAuth token was received in the query string, which this API forbids for response formats other than JSON or XML. If possible, try sending the OAuth token in the Authorization header instead."
}
],
"code": 400,
"message": "The OAuth token was received in the query string, which this API forbids for response formats other than JSON or XML. If possible, try sending the OAuth token in the Authorization header instead."
}
}
An odd error message. Authenticating with a header instead of an access_token parameter doesn't make it work. I used the API explorer found for the realtime resource (https://developers.google.com/drive/v2/reference/realtime/get) and it didn't work either. It gives the following message when used with the same file:
400 Bad Request
- Hide headers -
cache-control: private, max-age=0
content-encoding: gzip
content-length: 123
content-type: application/json; charset=UTF-8
date: Tue, 05 Aug 2014 03:14:42 GMT
expires: Tue, 05 Aug 2014 03:14:42 GMT
server: GSE
{
"error": {
"errors": [
{
"domain": "global",
"reason": "invalid",
"message": "Invalid Value"
}
],
"code": 400,
"message": "Invalid Value"
}
}
I know the file is fine because the rest of the API calls I've made against it have worked (exploring the comments functionality and other things). It's frustrating issue I've run against, but hopefully someone can help. I would like to be able to edit collaborative documents outside of the canonical browser based editor in a non-destructive way!
Small update:
GET https://www.googleapis.com/drive/v2/files/1s8NArXPG0CWRHaA9HQ-zND086Uh5CoUFC2p3b3NI3Ek/realtime?key={YOUR_API_KEY}
Is the URL the API explorer (found here https://developers.google.com/drive/v2/reference/realtime/get) shows itself using to get the 400 error message above. As it turns out, I'd only set up an OAuth2 client ID - a "Simple API Key" is needed for the realtime API. A server side API key will not work either - it must be an API key for an Android application, iOS application or a browser based application. This is horrendously inconvenient because I'm not interested in browser based anything, but maybe there's some way to write a small hosted shim to make my dreams come true. Why must you do this, Google??!?
You cannot use the realtime API to access existing documents. It is for creating your own custom data, collaborative data models.
I am trying to build a web app that lets the customer add demo data to any Salesforce instance. My demo builder uses OAuth 2 Authorization Code Grant.
I am trying to get the switch instance portion working. However once the user connects to one instance
GET /services/oauth2/authorize?response_type=code&client_id=blabla.UKP&redirect_uri=https%3A%2F%2Fsfblademo.bla.com%2Foauth%2Fcallback HTTP/1.1
Host: na9.salesforce.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.12 Safari/535.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: cookie_bla; disco=5:00D50000000Ii39:00550000001ifEp:0|; autocomplete=1; inst=APP5
It redirects to the previous instance. Seems like its reading cookies and redirecting
HTTP/1.1 302 Found
Server:
Location: https://na3.salesforce.com/setup/secur/RemoteAccessAuthorizationPage.apexp?source=blablabla
Content-Type: text/html
Content-Length: 525
Date: Fri, 16 Sep 2011 21:46:58 GMT
The URL has moved here
Is there a way to sign out or clear the cookies salesforce has. I am not running my app on salesforce.
Thanks !
The API logout() call isn't going to work because that will only invalidate the API session and not the UI session stored in the browser cookie on the *.salesforce.com domain, to which your app won't have direct access. That's not to say it isn't still recommended, but to clear that UI cookie, you'll need to redirect the end user to /secur/logout.jsp on the instance_url of the previous session. To make it transparent to end users, you can load it in a hidden iframe like this:
<iframe src='https://{instance_url}/secur/logout.jsp' width='0' height='0' style='display:none;'></iframe>
Before switching to other instance, you can try making the logout call, as described here WS Guide :http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_calls_logout.htm
This will invalidate the previous session hopefully..
A web-server is returning a status code and description in response to a request by an XmlHttp component. The actual status response from the server begins with:
HTTP/1.1 400 Not a valid http POST request
which i can see in though a Fiddler trace:
But when i ask the xmlHttp request for the status and statusText, it shows me the "standard" description for the status text, rather than the actual status text:
xmlHttp.status: 200
xmlHttp.statusText: "Bad Request"
which i can see in in the development IDE:
i've poked around all the other properties of IXMLHttpRequest, and i can't find any that contain the response's actual status text. It's not even in any of the response headers:
Server: ASP.NET Development Server/8.0.0.0
Date: Thu, 28 Jan 2010 21:03:16 GMT
X-AspNet-Version: 2.0.50727
X-LSI-Proxy-Identificaton: {65B76AB2-8A28-4A2B-B282-7E1FDC9DBCA1}
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/xml; charset=utf-8
Content-Length: 4652
Connection: Close
Internet Explorer, Chrome, and FireFox manage to read the actual status text:
How can i get the actual statusText from a Microsoft xmlHttp object?
Unfortunately code 400 is defined as Bad Request as part of the HTTP/1.1 RFC and XMLHTTP (well more likely URLMON or WinHTTP) is just transforming the number and ignoring the passed status text. As the status line is part of the protocol and not a response header then it makes sense it isn't defined in the list of response headers.
However I would contend that the browsers are only showing the status text "correctly" because they are displaying the custom HTML page which got sent along with it which has that text as the TITLE in the HEAD element.