I have a Windows Server 2019 running an IIS web server. My organization uses ADFS 2016 and a team has configured the IdP integration in ADFS on my behalf. Everything (accounts, server, etc) are part of an AD domain network (all within same domain infrastructure).
I am building a .NET 6 app and deploying to the server using this example which uses itfoxtec-identity-saml2: How to Authenticate with SAML in ASP.NET Core and C#
The app launches fine. When I click the login button I'm presented with an error upon redirect back to the app: "HTTP ERROR 400".
Browser console:
x Failed to load resource: the server responded with a status of 400 () chrome-error://chromewebdata/:1
crbug/1173575, non-JS module files deprecated. (anonymous) # VM9:2762
Header data from the developer console:
Request URL: https://oitctxwbdcsp1.deleted/ADFSTest
Request Method: POST
Status Code: 400
Remote Address: 10.137.0.7:443
Referrer Policy: strict-origin-when-cross-origin
date: Tue, 29 Mar 2022 21:02:57 GMT
server: Microsoft-IIS/10.0
strict-transport-security: max-age=0; includeSubDomains
:authority: oitctxwbdcsp1.deleted
:method: POST
:path: /ADFSTest
:scheme: https
accept
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
cache-control: no-cache
content-length: 3813
content-type: application/x-www-form-urlencoded
origin: https://dev.adfs.federation.deleted
pragma: no-cache
referer: https://dev.adfs.federation.deleted/
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="98", "Microsoft Edge";v="98"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
sec-fetch-dest: document
sec-fetch-mode: navigate
sec-fetch-site: same-site
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.119 Safari/537.36 Edg/98.0.1108.76
SAML Response (decoded)
<samlp:Response ID="_df09235a-cd8e-40bf-a5b4-03aa6c1bf55e" Version="2.0" IssueInstant="2022-03-29T21:02:57.580Z" Destination="https://oitctxwbdcsp1.*deleted*/ADFSTest" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_ca71b9ef-4bf8-45b3-930c-a7bbe58a0dc0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://dev.adfs.federation.*deleted*/adfs/services/trust</Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /><ds:Reference URI="#_df09235a-cd8e-40bf-a5b4-03aa6c1bf55e"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /><ds:DigestValue>3Z+f+F61txOvBDBdtd2TXlt51Gs8mxXgtBJQu4zVXfE=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>X2hy*deleted*</ds:SignatureValue><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><ds:X509Certificate>MIIC8*deleted*</ds:X509Certificate></ds:X509Data></KeyInfo></ds:Signature><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" /></samlp:Status></samlp:Response>
RelayState: https://oitctxwbdcsp1.*deleted/ADFSTest/=%2F
Additional Info:
The ADFS IdP reads metadata from a URL that I have provided them. The metadata looks like this:
<?xml version="1.0"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
validUntil="2032-03-12T19:19:05Z"
cacheDuration="PT604800S"
entityID="https://oitctxwbdcsp1.*deleted*">
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://oitctxwbdcsp1.*deleted*/ADFSTest" index="0" />
</md:SPSSODescriptor>
</md:EntityDescriptor>
The appsettings.json is as follows:
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft": "Warning",
"Microsoft.Hosting.Lifetime": "Information"
}
},
"Saml2": {
"IdPMetadata": "https://dev.adfs.federation.*deleted*/federationmetadata/2007-06/federationmetadata.xml",
"Issuer": "https://oitctxwbdcsp1.*deleted*",
"SignatureAlgorithm": "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256",
"CertificateValidationMode": "ChainTrust",
"RevocationMode": "NoCheck"
},
"AllowedHosts": "*"
}
I am new to SAML2 and authentication in general.
You are getting an error in the SAML Response from AD FS. The error status is urn:oasis:names:tc:SAML:2.0:status:Responder.
There is an error on AD FS stopping the login sequence.
Related
Below is My Request Header , access-control-allow-origin is already set to * in Request Header as shown below but still CORS Error is coming (it's coming only when trying to upload a empty file)
:authority: storage.googleapis.com
:method: PUT
:path: /sms-local-bucket/3f9e2365-8d03-40e2-9635-a3d1860a7f23/8a70f7a3-59ff-4d36-b0ce-8e32efe55493?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=sfs-local%40revbits-sfs-local.iam.gserviceaccount.com%2F20211029%2Fauto%2Fstorage%2Fgoog4_request&X-Goog-Date=20211029T034429Z&X-Goog-Expires=61&X-Goog-SignedHeaders=content-type%3Bhost%3Bx-goog-resumable&X-Goog-Signature=0def04860fcda4d9c316544eef3482491e4f70cd4f9e397fe282b03a728b9f91465f3669f616e5e6fde72a765ca872624ed3d2ff60f5fa3735cabc03d640e409e2240a58229e23ee882e37998c038ca1c9b8e47dbc38765a9056b2c14268bcbf6595d21a9056b5df1b8808a5fde0d83b9b2d815482a073c8ca7662c872aa01a6884baea466cacf05c2b39c09ab1d0b7838b31f7c96d7f4c470fcff4cc753d5cc00122077d1cbbfb40ce715644a6c85a53c68349b8d7831a31cd3f8006840658a9516209d1f128d84c34961597ec148992caf5e3b4e141144632bd2a5b82528d127a3816840ebb063de8376ee1fc9c3a70894057e9adab9ff58b7de4e99d23f09&upload_id=ADPycdtHTqXlDLRx1GxLY6W3FsJHuxT0VJJNqtdPpQ3DxlfS8TvCeTjOFhDSTQCsrb2VMGgnAER1CPNOStNV2Uus4WSTJpzsGQ
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: en-GB,en-US;q=0.9,en;q=0.8
access-control-allow-origin: *
content-length: 0
content-range: bytes 0--1/0
content-type: application/octet-stream
origin: http://localhost:3000
referer: http://localhost:3000/
sec-ch-ua: "Google Chrome";v="93", " Not;A Brand";v="99", "Chromium";v="93"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Linux"
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36
x-client-data: CJG2yQEIorbJAQipncoBCO/yywEInvnLAQjnhMwBCPqEzAEItYXMAQjLicwB
Decoded:
message ClientVariations {
// Active client experiment variation IDs.
repeated int32 variation_id = [3300113, 3300130, 3313321, 3340655, 3341470, 3342951, 3342970, 3343029, 3343563];
}
If you create the application in localhost header('Access-Control-Allow-Origin: *'); and if it is not working, install the CORS Everywhere plugin in your browser and then check the response and it will work fine.
Plugin URL :
For Firefox : https://addons.mozilla.org/en-US/firefox/addon/cors-everywhere/
For Chrome : https://chrome.google.com/webstore/detail/allow-cors-access-control/lhobafahddgcelffkeicbaginigeejlf?hl=en
Also, Chrome does not support localhost for CORS requests (an error opened since 2010) [1], if you inspect the thread of this error.
For more information on CORS, please refer to the following document[2].
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=67743
[2] https://cloud.google.com/storage/docs/xml-api/put-bucket-cors
TLDR:
The following response header doesn't set the cookie in browser:
Access-Control-Allow-Origin: *
Allow: GET, HEAD, OPTIONS
Content-Length: 7
Content-Type: application/json
Date: Tue, 27 Apr 2021 15:58:02 GMT
Referrer-Policy: same-origin
Server: WSGIServer/0.2 CPython/3.9.4
Set-Cookie: csrftoken=r5r2YcZZvJKs79cbLd24VSyNscpUsxJB6UuWiWO2TXriy6B4r8KDZrwSDyI091K1; expires=Tue, 26 Apr 2022 15:58:02 GMT; Max-Age=31449600; Path=/; SameSite=Lax
Vary: Accept, Cookie, Origin
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
My request headers:
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cache-Control: no-cache
Connection: keep-alive
Host: 127.0.0.1:8000
Origin: http://localhost:3000
Pragma: no-cache
Referer: http://localhost:3000/
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36
I am new to Django, react and "http header" related stuff.
My django dev server runs at:
http://127.0.0.1:8000/
and my react dev server runs at:
http://127.0.0.1:3000
In order to access the website, login is required. So, all unauthorized requests are 1st redirected to login page, by configuring react-router and following this template. So, till now, no api calls are made.
In order to post login data, i need to have csrf token set by the server. But since i have not made any api calls, i created an endpoint /api/csrf/ explicitly, to set the csrf token.
# URL: /api/csrf/
class CSRFGet(APIView):
"""
Explicitly set csrf cookie
"""
#method_decorator(ensure_csrf_cookie)
def get(self, request):
return Response('hello')
I call this endpoint, when useProvideAuth hook is mounted.
function useProvideAuth() {
const [token, setToken] = useState(null);
const login = (username, password) => {
return axios.post(
'/auth/',
{
username: username,
password: password
})
.then(response => {
setToken(response.token)
})
}
useEffect(()=> {
axios.get(
'/csrf/'
)
},[])
return {
token,
login,
}
}
To retrieve and set this cookie, i followed the official Django docs. I also enabled CORS policy using django-CORS-headers allow all origins.
Now, when i make a request to any page, it redirects to login page, and i can see api/csrf/ responds with:
Set-Cookie: csrftoken=LgHo2Y7R1BshM4iPisi5qCXhdHyAQK7hD0LxYwESZGcUh3dXwDu03lORdDq02pzG; expires=Tue, 26 Apr 2022 06:29:23 GMT; Max-Age=31449600; Path=/; SameSite=Lax
But, the cookie is not set at all. Why is it so?
Is my approach for getting csrf cookie correct? Please let me know, if i am making any security vulnerability with this approach.
Could you try adding the following to the django-cors-headers configuration and retry?
CORS_ALLOW_CREDENTIALS = True
Also, please note that the above configuration would probably not work if you are allowing all origins. See this Mozilla documentation: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’
If you face such error, I suggest setting:
CORS_ALLOWED_ORIGINS = [
"http://127.0.0.1:3000",
]
or something fancier like:
CORS_ALLOWED_ORIGIN_REGEXES = [
r"^http://127.0.0.1:[0-9]{1,4}$",
]
Finally, make sure that you are using a django-cors-headers version >= 3.5 since the 2 above configuration had different aliases back then.
Let me know if it works, I am very curious.
Turns out the issue was, i was using http://127.0.0.1:8000 to make api calls, where as my server was on http://localhost:8000. Because of this, host and origin, in my request headers didn't match the same domain.
Cookies can be allowed to be used under same domain, with different ports and subdomains, unlike Same-Origin policy, but cannot be used cross-domains.
In my case, I guess http://127.0.0.1:8000 & http://localhost:8000 were considered different domains, and thus the browser was not setting my cookie.
Thanks Anas Tiour, for stating about Allow-Credentials. I had tried that too, but still had no luck until i found out the actual reason.
I've got quite random occurrence with this common error:
OPTIONS https://api.cloudfunctions.net/api/graphql 404
Access to fetch at 'https://api.cloudfunctions.net/api/graphql' from origin 'https://website.com' 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. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
What I have is a graphql endpoint with apollo server deployed on Google Cloud Functions and a react client. At some points the client will throw the error on browser but if I try refresh or send the request again 2 or 3 times later it will work.
The preflight request headers being sent:
:authority: api.cloudfunctions.net
:method: OPTIONS
:path: /api/graphql
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,id;q=0.8,ms;q=0.7
access-control-request-headers: content-type
access-control-request-method: POST
origin: https://website.com
referer: https://website.com/
sec-fetch-mode: cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
Expected response
access-control-allow-credentials: true
access-control-allow-headers: content-type
access-control-allow-methods: POST,OPTIONS
access-control-allow-origin: https://website.com
alt-svc: quic=":443"; ma=2592000; v="46,43",h3-Q050=":443"; ma=2592000,h3-Q049=":443"; ma=2592000,h3-Q048=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000
content-length: 0
content-type: text/html
date: Wed, 08 Jan 2020 00:38:16 GMT
function-execution-id: 84et92k6mvd9
server: Google Frontend
status: 200
vary: Origin, Access-Control-Request-Headers
x-cloud-trace-context: 95d25375171148a66bc629cc41a79d05
x-powered-by: Express
Random failed response
alt-svc: quic=":443"; ma=2592000; v="46,43",h3-Q050=":443"; ma=2592000,h3-Q049=":443"; ma=2592000,h3-Q048=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000
cache-control: private
content-encoding: gzip
content-length: 140
content-security-policy: default-src 'none'
content-type: text/html; charset=utf-8
date: Wed, 08 Jan 2020 00:38:05 GMT
function-execution-id: 84etgky3im1k
server: Google Frontend
status: 404
x-cloud-trace-context: 77040d2c72304cad0d645480b6814f7f;o=1
x-content-type-options: nosniff
x-powered-by: Express
Looking at the failed response above kinda make sense that it's missing the access-control-allow-* headers compared to success one, but again I am not sure how that happened.
Here's my cors config:
const corsConfig = {
origin: ['https://website.com', 'http://localhost:3000'],
methods: ['POST', 'OPTIONS'],
credentials: true,
optionsSuccessStatus: 200,
}
const app = express()
app
.use(cors(corsConfig))
.use(...)
...
apolloServer.applyMiddleware({ app, cors: corsConfig })
Based on few suggestions around I have tried different setup but still sometimes the error happens:
set cors: false in applyMiddleware
remove cors
repeat cors as shown above
add app.options('*', cors()) as per doc says
All and all it happens like 1 in 10, sometimes on first request after the user open the site the other times after the user browsing around the site for a while.
I think there might be other middleware that messes up your cors settings.
You can try use a different path for your graphql endpoint, and apply cors only to that path.
apolloServer.applyMiddleware({ app, path: '/graphql', cors: corsConfig });
Alternatively, you can try the express cors middleware and disable the cors from apollo server
I used the apollo-server-cloud-functions package to solve this problem. Just follow the instructions here (https://github.com/apollographql/apollo-server/tree/master/packages/apollo-server-cloud-functions) but instead of using exports.handler = server.createHandler() swap it out for your own function, like this:
exports.api = functions.https.onRequest(
server.createHandler({
cors: {
origin: true,
credentials: true
}
})
);
That solved it for me!
I'm in the process of building an internal application where I am using Angular 2 (CLI/Webpack) to call a CORS enabled service that I built using .NET Core. The service uses the user's Integrated Windows Authentication credentials to look up information about that user and return it to Angular. Everything works fine in Chrome and Firefox, but in IE 10 and 11, I receive a "401 Unauthorized" response with the message Origin http://localhost:4200 not found in Access-Control-Allow-Origin header.
In Angular, I'm making an HTTP call like so:
private options = new RequestOptions({withCredentials: true});
let getURL = `server:port/api/users/username`;
return this.http
.get(getURL, this.options)
.map((response: Response) => response.json()[0])
.catch(this.handleError);
and my .NET Core service uses the following code in Startup.cs:
public void ConfigureServices(IServiceCollection services)
{
services.AddCors(options =>
{
options.AddPolicy("policyAnyone",
builder => {
builder.AllowCredentials()
.AllowAnyOrigin()
.AllowAnyMethod()
.AllowAnyHeader();
});
});
services.AddApplicationInsightsTelemetry(Configuration);
services.AddMvc();
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
loggerFactory.AddConsole(Configuration.GetSection("Logging"));
loggerFactory.AddDebug();
app.UseCors("policyAnyone");
app.UseApplicationInsightsRequestTelemetry();
app.UseApplicationInsightsExceptionTelemetry();
app.UseMvc();
}
The controller then uses the username it receives via User.FindFirst(ClaimTypes.Name).Value, runs a stored procedure, and returns the results.
For reference, Chrome has the following request headers:
Accept: application/json, text/plain, `*/*`
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Authorization: Negotiate %lotsOfEncodedText%
Cache-Control: max-age=0
Connection: keep-alive
content-type: text/plain
Host: server:port
Origin: http://localhost:4200
Referer: http://localhost:4200/dashboard
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36
and IE has these:
Request: GET /api/users/username HTTP/1.1
Accept: application/json, text/plain, `*/*`
Content-Type: text/plain
Referer: http://localhost:4200/dashboard
Accept-Language: en-US
Origin: http://localhost:4200
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: server:port
Connection: Keep-Alive
Cache-Control: no-cache
It seems as though CORS is configured correctly, and my Angular setup is pretty simple, but IE doesn't even display the credentials box.
In case anyone runs across this, I think I was able to solve the problem. My issue is with my PC's Internet Options where the Logon Authentication option (Internet Options > Security > Custom level... > User Authentication > Logon) was set to "Automatic logon only in Intranet zone". While this is intended, IE wasn't seeing my site as an intranet site, but rather an internet site. The reason for this is the "dot rule" that IE uses.
"If the URI’s hostname doesn’t contain any periods (e.g. http://team/) then it is mapped to the Local Intranet Zone." [1]
Our local site's hostname contains periods and is therefore mapped to the Internet Zone. After we are able to cut through the red tape, manually adding my site to the Local Intranet Zone (Internet Options > Security > Local Intranet > Sites > Advanced) should fix my issue.
I'm not sure why IE decided to respond with the CORS ACAO error message that it did, but the 401: Unauthorized response was at least enough to tip me off.
[1] Info on the Internet Option: https://support.microsoft.com/en-us/help/258063/internet-explorer-may-prompt-you-for-a-password
[2] Info on the Intranet Zone determination: https://blogs.msdn.microsoft.com/ieinternals/2012/06/05/the-intranet-zone/
IE treats ports differently than other browsers. Other browsers say that if the port is different, then it is not the same "origin". In IE, if the ports are different but the domain is the same, then it is same origin and the headers are not used.
You can read more here : https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#IE_Exceptions
However you should still see the returned data via Angular (Since IE would just treat them as same origin). So are you seeing response data at all from your ajax call?
I am working on an angular-laravel app. I have an API kind of workflow.
The angular app sits at the root of the project directory in the angular folder.This has the build tools and dependency management tools configured like bower and grunt.
My routes.php has been configured to authenticate the user on login.
Route::post('login','LoginController#auth');
Route::get('checkAuthentication','LoginController#isLoggedIn');
When I call both the routes,I always get the response as false.
Tried printing the values in the Auth::attempt() method,which logs in the user,but the session does not persist.The user is immediately thrown out to the home page.
I start the applcication using grunt by running grunt serve. This starts the app on localhost:9000. I call the laravel routes from angular by giving path to the public folder as they are laravel routes. Example: localhost/project_dir/public/login. This check the user in database but immediately destroy or does not create session even after adding CORS extension. NO error is displayed.Just false is returned and the user is redirected to home page.
Remote Address:127.0.0.1:80
Request URL:http://localhost/project_dir/public/user/check
Request Method:POST
Status Code:200 OK
Response Headers
view source
Access-Control-Allow-Origin:http://localhost:9000
Cache-Control:no-cache
Connection:Keep-Alive
Content-Length:4
Content-Type:text/html; charset=UTF-8
Date:Wed, 29 Jul 2015 10:30:33 GMT
Keep-Alive:timeout=5, max=99
Server:Apache/2.4.9 (Win64) PHP/5.5.12
Set- Cookie:laravel_session=eyJpdiI6InlaVVlxUDRra3E1NXdcL25OekJvSlBRPT0iLCJ2YWx1ZSI6IlVaWGF6NmdsV1wvZ3NcL1FTVkR5Y2J3czlQNUkyaWdxZlJmeG5zK2U2c0lqM2VOMEY5S000cVwveTBVazBwVFNSZXlhZmhWSEUxUlRyMVJidE5TcE5jM2FBPT0iLCJtYWMiOiIzYzQ2YjJkMjVmMjZiODBiNzgwNmY3YjQ3NmMwOWI5MmM3NmFmZmNmMzY1MDFkNjFlMjg0MjQ0MzVjNGUyYTAzIn0%3D; expires=Wed, 29-Jul-2015 12:30:33 GMT; Max-Age=7200; path=/; domain=http://localhost:9000/; httponly
Vary:Origin
X-Powered-By:PHP/5.5.12
Request Headers
view source
Accept:application/json, text/plain, */*
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Content-Length:0
Host:localhost
Origin:http://localhost:9000
Referer:http://localhost:9000/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.107 Safari/537.36 FirePHP/4Chrome
X-FirePHP-Version:0.0.6
X-Wf-Max-Combined-Size:261120
Above are request response headers for a route to check users session.
How can I debug it to resolve the issue? Is it angular rejecting the request?
Update:
I tried disabling the laravel_session cookie using this link but still no luck
Remote Address:127.0.0.1:80
Request URL:http://localhost/project_dir/public/user/check
Request Method:POST
Status Code:200 OK
Response Headers
view source
Access-Control-Allow-Origin:http://localhost:9000
Cache-Control:no-cache
Connection:Keep-Alive
Content-Length:4
Content-Type:text/html; charset=UTF-8
Date:Wed, 29 Jul 2015 13:41:51 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.4.9 (Win64) PHP/5.5.12
Vary:Origin
X-Powered-By:PHP/5.5.12
Request Headers
view source
Accept:application/json, text/plain, */*
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Content-Length:0
Host:localhost
Origin:http://localhost:9000
Referer:http://localhost:9000/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.107 Safari/537.36