Setting cookies cross-domain? node and react - node.js

I am building a node express rest app with react frontend. At development the backend is running at localhost:5000 and the frontend at localhost:3000. I am using session based authentication system. So I am sending a Set-Cookie header when authentication is successful from the backend. But the problem is that since the frontend and the backend area on different domains the cookie cannot be set.
What can be done?
Plus, I do not want to use the JWT for authentication for the reasons laid out at http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
Middleware
const cors = require('cors');
app.use(cors({ credentials: true, origin: 'http://localhost:3000' }));
Following is the header sent back from the backend
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 129
Content-Type: application/json; charset=utf-8
Date: Sun, 22 Dec 2019 14:24:03 GMT
ETag: W/"81-RZ35EekMxvCHWWNZ8hxPVFlS+R8"
Set-Cookie: connect.sid=s%3Afa5CxZSLQznDHuO7I6y9qAfy5-VuezUj.I%2F3BP6vfXybkyUXej6%2Fjt5ribqmmfoy1NQfSImuNYaU; Path=/; Expires=Sun, 29 Dec 2019 14:24:03 GMT; HttpOnly
Strict-Transport-Security: max-age=15552000; includeSubDomains
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block

Related

Azure Staging Environment "No 'Access-Control-Allow-Origin' header is present on the requested resource"

I've inherited a web-app hosted in Azure and it appears the staging environment CORS is not functioning like all other environments.
I'm fairly new to Azure administration and I've applied the CORS configuration on the API app service (previously had no config set) which did not resolve the issue.
You can compare the different environment general/response headers below.
Local Dev...
Request URL: http://localhost:3001/api/getstarted/plans?fetchExcluded=true
Request Method: GET
Status Code: 200 OK
Remote Address: [::1]:3001
Referrer Policy: strict-origin-when-cross-origin
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Encoding: gzip
Content-Type: application/json; charset=utf-8
Date: Thu, 04 Nov 2021 21:55:22 GMT
Keep-Alive: timeout=5
Strict-Transport-Security: max-age=15552000; includeSubDomains
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Current Production...
Request URL: https://api.<webapp>.app/api/getstarted/plans?fetchExcluded=true
Request Method: OPTIONS
Status Code: 204 No Content
Remote Address: ##.###.###.###:443
Referrer Policy: strict-origin-when-cross-origin
Access-Control-Allow-Headers: authorization
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
Access-Control-Allow-Origin: *
Date: Thu, 04 Nov 2021 22:04:19 GMT
Strict-Transport-Security: max-age=15552000; includeSubDomains
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
However in staging...
Request URL: https://<webapp>.azurewebsites.net/api/getstarted/plans?fetchExcluded=true
Request Method: OPTIONS
Status Code: 503 Service Temporarily Unavailable
Remote Address: ##.###.###.###:443
Referrer Policy: strict-origin-when-cross-origin
Content-Length: 398
Date: Thu, 04 Nov 2021 21:56:02 GMT
Server: nginx
and from debug console in staging...
- Access to XMLHttpRequest at
'https://<webapp>.azurewebsites.net/api/getstarted/plans?fetchExcluded=true'
from origin 'https://<webapp>.z8.web.core.windows.net' has been
blocked by CORS policy: Response to preflight request doesn't pass
access control check: No 'Access-Control-Allow-Origin' header is
present on the requested resource. xhr.js:178
- GET
https://<webapp>-api-staging.azurewebsites.net/api/getstarted/plans?fetchExcluded=true
net::ERR_FAILED
I've checked the Azure Subscription usage + quotas, and the only thing nearing quota is "Network Watchers"
The API framework is ExpressJS with CORS...
app.use(cors())
In my opinion the issue has nothing to do with CORS, well, better said,...
As you can see in the staging environment you are receiving a 503, service unavailable, HTTP status error code:
Status Code: 503 Service Temporarily Unavailable
So my guess is that the staging environment is not working properly by some reason, and the associated load balancer is returning a 503 error page, of course, without any CORS indication, and your browser is complaining due to the fact your API doesn't receive a valid response.
Please, review the status of the staging environment: once healthy, it probably will offer a proper response to your application.
Unfortunately the issue was not CORS at all; rather the server image was failing to build and compile due to ESNext JS syntax (server < ESNext)
I found the logstream API which allowed me to view all errors, for posterity you might be able to find the same; https://<webapp>.scm.azurewebsites.net/api/logstream

Gmail API throwing 401 Unauthorized

I'm trying to integrate Gmail API in my app in order to send emails to users.
i've created a project on Google Developers Console, enabled Gamil API in it, downloaded the credentials as JSON and followed the instruction provided at https://developers.google.com/gmail/api/quickstart/nodejs
I've also added https://developers.google.com/oauthplayground as a redirect URI for the project.
When I run the code, I get redirected to a consent screen. I choose the account which has the project, then get redirected to "oauthplayground"
However, when I try to exchange authorization code for tokens, I receive 401 unauthorized
the full response is:
HTTP/1.1 401 Unauthorized
Content-length: 75
X-xss-protection: 0
X-content-type-options: nosniff
Transfer-encoding: chunked
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Vary: Origin, X-Origin, Referer
Server: scaffolding on HTTPServer2
-content-encoding: gzip
Pragma: no-cache
Cache-control: no-cache, no-store, max-age=0, must-revalidate
Date: Wed, 21 Oct 2020 07:53:18 GMT
X-frame-options: SAMEORIGIN
Alt-svc: h3-Q050=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
Content-type: application/json; charset=utf-8
{
"error_description": "Unauthorized",
"error": "unauthorized_client"
}
Any help is appreciated
Thanks

Express API returns duplicate "100 continue" responses when it should only return one

Problem description
When making a HTTP POST request to my Express app (Node.js) the server responds with two "100 Continue" responses and after that a "200 OK" response, when there should only be one "100 Continue".
Postman manages to ignore the second "100 continue" and reports success but another app I'm building with Mule ESB doesn't accept the extra "100 continue" and fails.
The app otherwise handles the POST request without any problems, data is written to the database and so forth.
About the technical enviroment
The Express app is running on a SUSE-server. Nginx serves as a reverse proxy. I manage the multiple Express apps with PM2.
At first i was using a separate Express app, with a proxy package, to act as a reverse proxy. But i switched it out to using Nginx as the reverse proxy, thinking that might have been the issue. But that made no difference.
I have tried the exact same setup with the express reverse proxy on my local machine and that doesn't return "100 Continue" at all, only "200 OK".
I can't figure out why the exact same app returns different responses when it's running on local/server.
Example response
**REQUEST**
POST /<my-endpoint> HTTP/1.1
Host: api.<my-server>.se:443
User-Agent: AHC/1.0
Connection: keep-alive
Accept: */*
Content-Type: application/json; charset=UTF-8
Content-Length: 123
**RESPONSE**
HTTP/1.1 100 Continue
Strict-Transport-Security: max-age=94608000
Date: Thu, 09 May 2019 10:11:34 GMT
Set-Cookie: WASID_HAG=f88cc3f3525ed06b; path=/; domain=.<my-domain>.se
Set-Cookie: WAAK_HAG=41ef118d9c4608f158cfbdcb0140e652; path=/; domain=.<my-domain>.se; secure
Set-Cookie: UPD=6; path=/; domain=.<my-domain>.se
Set-Cookie: RGSC16972=1030; path=/; domain=.<my-domain>.se
HTTP/1.1 100 Continue
Strict-Transport-Security: max-age=94608000
Date: Thu, 09 May 2019 10:11:34 GMT
Set-Cookie: WASID_HAG=f88cc3f3525ed06b; path=/; domain=.<my-domain>.se
Set-Cookie: WAAK_HAG=41ef118d9c4608f158cfbdcb0140e652; path=/; domain=.<my-domain>.se; secure
Set-Cookie: UPD=6; path=/; domain=.<my-domain>.se
Set-Cookie: RGSC16972=1030; path=/; domain=.<my-domain>.se
HTTP/1.1 200 OK
Server: nginx/1.16.0
Date: Thu, 09 May 2019 10:11:34 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 227
Access-Control-Allow-Origin: *
X-DNS-Prefetch-Control: off
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Download-Options: noopen
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
ETag: W/"e3-aMSDU6iiOn52HqHZuJKLaZNt38k"
Set-Cookie: WASID_HAG=f88cc3f3525ed06b; path=/; domain=.<my-domain>.se
Set-Cookie: WAAK_HAG=41ef118d9c4608f158cfbdcb0140e652; path=/; domain=.<my-domain>.se; secure
Set-Cookie: UPD=6; path=/; domain=.<my-domain>.se
Set-Cookie: RGSC16972=1030; path=/; domain=.<my-domain>.se
Cache-control: no-store
What could be causing the multiple "100 Continue" responses and how can i prevent them?
Since the app doesn't return any "100 Continue" responses at all on my local machine could there be something with the server/firewall that's causing this?

Why does WinINET change from using Kerberos to NTLM when responding to an auth demand when using Windows Authentication?

We are currently loadtesting a Sharepoint environment hosted in IIS8.5 (On Windows 2012R2), using Loadrunner 11.52. We are using the WinINET based replay mechanism as there were SSL issues when trying to use the LR sockets implementation.
The authentication for the site is set to allow Windows Authentication. The users are all unique Active Directory users.
We have an issue where after starting 50 users, the users start failing due to them being unable to authenticate.
We have captured both successful (first 50 users) authentication and unsuccessful (users after the first 50) auth using Fiddler.
On initially loading the web page, the server returns a 401 with authentication headers as expected:
Request:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Response:
HTTP/1.1 401 Unauthorized
Content-Type: text/plain; charset=utf-8
Server: Microsoft-IIS/8.5
SPRequestGuid: ad71f69c-0b10-d049-46c6-1f0b1f7bd574
request-id: ad71f69c-0b10-d049-46c6-1f0b1f7bd574
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 2
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:13:44 GMT
Content-Length: 16
Proxy-Support: Session-Based-Authentication
401 UNAUTHORIZED
WinINET then handles this appropriately, returning a Kerberos auth token, which the server accepts:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate YIISMQYGKwYBBQUCoIISJTCCEiGgMDAuB...<long-auth-token-string>...=
Response:
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: text/html; charset=utf-8
Expires: Wed, 11 Mar 2015 07:13:44 GMT
Last-Modified: Thu, 26 Mar 2015 07:13:44 GMT
Vary: Accept-Encoding
Server: Microsoft-IIS/8.5
X-SharePointHealthScore: 0
X-AspNet-Version: 4.0.30319
SPRequestGuid: ad71f69c-db17-d049-46c6-15c51828a26e
request-id: ad71f69c-db17-d049-46c6-15c51828a26e
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 40
SPIisLatency: 0
WWW-Authenticate: Negotiate oYGzMIGwoAMKAQChCw...<long auth token>...=
Persistent-Auth: true
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:13:44 GMT
Content-Length: 80492
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html dir="ltr" lang="en-US">
<head><meta name="GENERATOR" content="Microsoft SharePoint" /><
...
Some googling has suggested that the "YIIS" at the beginning of the auth token indicates that it has chosen Kerberos in response to the Negotiate auth option. This works fine for the first 50 users we start (each with unique AD user credentials).
However, for the 51st user, and each subsequent user, WinINET seems to start attempting to use NTLM authentication instead, which the server rejects.
Request (same as previously successful user):
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Response (same as previously successful user):
HTTP/1.1 401 Unauthorized
Content-Type: text/plain; charset=utf-8
Server: Microsoft-IIS/8.5
SPRequestGuid: 6a71f69c-6b4f-d049-46c6-1e90257415f1
request-id: 6a71f69c-6b4f-d049-46c6-1e90257415f1
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 1
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 16
Proxy-Support: Session-Based-Authentication
401 UNAUTHORIZED
Client then sends the request for auth:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate TlRMTVNTUAABAAA...<short NTLM auth token>...==
Some googling suggests that the T1R at the start of the auth token means it has chosen to use NTLM this time, instead of Kerberos which was used for all the users up till this one.
The server responds with another 401 to this:
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate TlRMTVNTUAACAAAACAAIADgAAAAVgonicMgf76hzy7QAAAAAAAAAAL4AvgBAAA...<long NTLM auth token>=
SPRequestGuid: 6a71f69c-cb6b-d049-46c6-14cbc16d1ea9
request-id: 6a71f69c-cb6b-d049-46c6-14cbc16d1ea9
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 1
SPIisLatency: 0
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 0
Proxy-Support: Session-Based-Authentication
Wininet then sends another auth request as follows:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAKIAAACEAYQBu...<much longer NTLM token>...=
Which results in another 401:
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.5
SPRequestGuid: 6a71f69c-cb6b-d049-46c6-18ce53703ae9
request-id: 6a71f69c-cb6b-d049-46c6-18ce53703ae9
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 236
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 0
Proxy-Support: Session-Based-Authentication
At this point WinINET seems to give up, and passes the 401 on to LoadRunner which then fails the user.
The first 50 users keep working as normal. We can also load another user manually through IE while those 50 are still running. We can also wait some time and eventually we can start more users.
So, there seems to be two issues here:
Why is WinINET changing to use NTLM auth instead of Kerberos after 50 users have been started?
Why is the server rejecting the NTLM auth.
Any ideas on what might be causing this, and/or how I can investigate further, would be very appreciated. My suspicion is that it may be some sort of Active Directory limit that blocks Kerberos from working for a period after 50 users have been authenticated, however I do not know how to prove/disprove that.
Thanks.

Page exists, google bot returning 404 error

I have website which is online. When I'am using it via browser everything is ok and this page is present in browser. When I'm using it as googlebot ( via webmastertools ) i'm getting error
HTTP/1.1 404 Not Found
Date: Mon, 19 Nov 2012 09:57:37 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: symfony=55240a0a341202d07fc96cbc1c1bcca5; path=/
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
and rest of the html code...
same thing when I'm trying to validate it via wc3 validator.
Please help :( I tryied everything :(
website address is mojaczestochowa.pl
If more info is needed please let me know.
Try to check the pae with web-sniffer and set user agent to google.bot
Here is the exact query, which will simulate server's response to the GoogleBot crawler:
https://websniffer.cc/?url=http://mojaczestochowa.pl/&uak=9

Resources