I am running Laravel 5.5 application in local development machine and in windows server 2012 production and there is no problem. However, when I deployed my application to Centos 6 Linux, the application produce Page inactivity error upon login. Investigation reveal that the cause of the error is that the request header cookie is not set.
My request header that works in my local development machine as follows:
...
Cache-Control max-age=0
Connection keep-alive
Cookie XSRF-TOKEN=eyJpdiI6InlGZ0l3OUV…3OGEzNWY5MDliOWVmZjYifQ%3D%3D
Host localhost
Referer http://localhost/abc/public/
Upgrade-Insecure-Requests 1
User-Agent Mozilla/5.0 (Windows NT 10.0; …) Gecko/20100101 Firefox/60.0
Response header as follows
...
Keep-Alive timeout=5, max=100
Server Apache/2.4.29 (Win32) OpenSSL/1.0.2l PHP/7.1.11
Set-Cookie XSRF-TOKEN=eyJpdiI6InFaMzI0QjV…:41 GMT; Max-Age=1799; path=/
Set-Cookie abc_app_session=eyJpdiI…5MjBkIn0%3D; path=/; HttpOnly
Transfer-Encoding chunked
X-Powered-By PHP/7.1.11
The corresponding request and response header from my linux production as follows
Request:
Connection keep-alive
Host www.abc.com
x-https 1
Upgrade-Insecure-Requests 1
User-Agent Mozilla/5.0 (Windows NT 10.0; …) Gecko/20100101 Firefox/60.0
Response:
Connection Keep-Alive
Content-Type text/html; charset=UTF-8
Date Sun, 24 Jun 2018 14:49:22 GMT
Keep-Alive timeout=5, max=100
Server Apache
Transfer-Encoding chunked
Without the XSRF token in the cookie, there is no way that Laravel 5.5 can verify against the session in the server and thus it will cause page inactivity. I have no clue but suspect it could be Linux permission issue that prevent cookie from being passed between client and server. I am using https connection for Linux. I tried the following but it is not working:
1- Using php artisan config:cache to clear all old cache and session
2- using php artisan view:clear to clear all views
3- chmod 755 to set permission to bootstrap/cache and storage folder recursively
4- chown apache to change owner grup of both bootstrap/cache and storage to apache.
5- session_driver=file
session_encrypt=false
Cache_driver=file
6- 'domain' => env('SESSION_DOMAIN', null),
'secure' => env('SESSION_SECURE_COOKIE', false),
'http_only' => true,
I am running out of clue what is the cause of the issue and how to fix it. Any help is appreciated.
Related
I am using a consul client to deregister a service from my junit tests. I am using vert-consul-client . the consul version i am using is 1.11.1 . the service is not registered with the consul , but just testing what will happen if we try to deregister a service that is not registered.
from the logs i get this error
Status message: 'Not Found'. Body: 'Unknown service "BadService"'
strangely i dont get this error when testing with 1.10.6 consul version.
appreciate if you can help
thanks
strangely i dont get this error when testing with 1.10.6 consul version.
Consul recently changed the HTTP response code that is sent when an attempt is made to deregister a non-existent service.
Prior to Consul 1.11.0, and when ACLs were disabled, Consul would respond with a HTTP 200 response code and no response body when deregistering a non-existent service.
$ curl --include \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 200 OK
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: allow
Date: Wed, 05 Jan 2022 03:07:35 GMT
Content-Length: 0
This behavior was changed in Consul 1.11.0 by PR hashicorp/consul#10632 wherein Consul now returns a HTTP 404 response code if a service does not exist, regardless of whether ACLs are enabled. (See diff of consul/agent/acl.go).
$ curl --include \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 404 Not Found
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: allow
Date: Wed, 05 Jan 2022 03:24:21 GMT
Content-Length: 22
Content-Type: text/plain; charset=utf-8
Unknown service "test"
You're obviously not seeing an error in vertx-consul-client when communicating to Consul 1.10.6 because the HTTP 200 code indicates that the request was successful, whereas the HTTP 404 response correctly signals that the resource does not exist, and an error is correctly raised (see vert-consul-client/src/main/java/io/vertx/ext/consul/impl/ConsulClientImpl.java#L1320-L1333).
Interestingly in Consul 1.10.x, when ACLs are enabled on the cluster, Consul would reply with a HTTP 500 error code and a corresponding error message instead of the 200 response code. This is because when ACLs are enabled, the vetServiceUpdateWithAuthorizer function does not prematurely return (if authz == nil { return nil }) and proceeds with checking whether service exists, then raising an error because it does not (see consul/agent/acl.go#L96-L104).
$ curl --include \
--header "X-Consul-Token: $CONSUL_HTTP_TOKEN" \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 500 Internal Server Error
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: deny
Date: Wed, 05 Jan 2022 03:14:52 GMT
Content-Length: 22
Content-Type: text/plain; charset=utf-8
Unknown service "test"
If you had tested 1.10.6 with ACLs enabled, you would've also received a similar error as you are seeing with 1.11.1.
I've set up apollo server on port 3000 on local host and it works fine. I can use the playground and make queries and they all work. ( some text pixilated for privacy )
However my front end is a Svelte application being served from port 8080 on localhost via snowpack. I've setup the snowpack config to proxy localhost:8080/api to localhost:3000
proxy: {
"/api": "http://localhost:3000/"
},
If I try to access the playground via http://localhost:8080/api then the web UI appears but there seem to be errors with the graphql protocol. The UI complains that the server cannot be reached
If I enter developer mode I see the following request failing
POST /api HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 1468
accept: */*
Apollo-Query-Plan-Experimental: 1
X-Apollo-Tracing: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36
DNT: 1
content-type: application/json
Origin: http://localhost:8080
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: http://localhost:8080/api/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-AU,en;q=0.9,de-AT;q=0.8,de;q=0.7,en-GB;q=0.6,en-US;q=0.5
with request body
The response given back is
HTTP/1.1 400 Bad Request
connection: close
Date: Thu, 12 Nov 2020 18:40:59 GMT
Content-Length: 0
Does something need to be configured with the server to allow it to work through a proxy like this?
I am using version 2.3.2 of elasticsearch. In my elasticsearch.yml file I have added the below lines to allow Cross-Origin requests.
http.cors.enabled: true
http.cors.allow-credentials: true
http.cors.allow-methods: OPTIONS,HEAD,GET,POST,PUT,DELETE
http.cors.max-age: 0
http.cors.allow-origin: /http?:\/\/localhost(:[0-9]+)?/
http.cors.allow-headers : X-Requested-With,X-Auth-Token,Content-Type,Content-Length
However, when i try to execute a query from Firefox, I get the following error;
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote
resource at http://localhost:9200/someIndex/_search?size=10&from=0.
(Reason: CORS header 'Access-Control-Allow-Origin' missing).
Replacing the http.cors.allow-origin parameter with "*", seems to work, but the documentation indicates this is a security requests.
The request headers from the browser are below;
Accept - application/json, text/plain, */*
Accept-Encoding - gzip, deflate
Accept-Language - en-US,en;q=0.5
Content-Length - 26
Content-Type - application/json;charset=utf-8
DNT - 1
Host - localhost:9200
Origin - null
User-Agent - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Firefox/44.0
Could someone please suggest what I am doing wrong in the above?
You seem to have a small typo.
It should read
http.cors.allow-origin: /https?:\/\/localhost(:[0-9]+)?/
^
|
add this
i.e. you're missing the s before the ?, which means "either http or https"
I seem to be having some problems with my Varnish set up. I have a clean install of Varnish and Nginx running on ubuntu, everything seems to be running, but I don't seem to be actually caching anything.
This is what im seeing:
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
X-Powered-By: PHP/5.5.9-1ubuntu4.14
Cache-Control: no-cache
Date: Tue, 02 Feb 2016 10:15:17 GMT
Content-Encoding: gzip
X-Varnish: 196655
Age: 0
Via: 1.1 varnish-v4
Accept-Ranges: bytes
Connection: keep-alive
I'm almost certain the problem is to do with the "age" response being 0. I have read that the Cache-Control header can be the culprit and have spent some time configuring both nginx and my vcl file with solutions I have read on-line, none of which have worked.
I'm open to any ideas even ones I have tried before (hence why im not listing the steps I have already taken).
Thanks in advance for any thoughts you might have.
Remove "no-cache" and set "max-age=120" (in seconds) in the Cache-Control header instead.
Also note that if the request contains any cookies or if the response sets any cookies than by default varnish is not gonna cache.
I try to figure out a cross-domain API issue.
I have an application created with Sencha Touch 2.3.1 that is using Ajax to fetch data from remote server.
The issue that I am facing is that all Ajax requests against local server does not contain all headers in response.
On remote server, all works fine and headers are ok.
Here are two prints that show the headers sent and received for each server individualy
1 - headers sent and received from localhost (http://local.api - vhost)
Headers received:
Connection Keep-Alive
Content-Length 274
Content-Type text/html; charset=iso-8859-1
Date Mon, 07 Jul 2014 10:58:54 GMT
Keep-Alive timeout=5, max=100
Location http://local.api/fa/?ref.agent/lista-clienti&_dc=1404730734262
Server Apache/2.2.17 (Win32) PHP/5.3.3
Headers sent:
Accept text/html,application/xhtml+xml,
application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language ro-ro,ro;q=0.8,en-us;q=0.6,en-gb;q=0.4,en;q=0.2
Content-Length 33
Content-Type application/x-www-form-urlencoded; charset=UTF-8
Host local.api
Origin http://sencha.local
Referer http://sencha.local/fisa-agenti/index.html
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101
Firefox/30.0
2 - headers sent and received from remote server (http://adgarage.ro)
Headers received
Accept-Ranges bytes
Access-Control-Allow-Cred... true
Access-Control-Allow-Orig... *
Age 0
Connection keep-alive
Content-Length 375
Content-Type application/json
Date Mon, 07 Jul 2014 10:58:52 GMT
Server Apache/2.2.22 (Unix) mod_ssl/2.2.22
OpenSSL/0.9.8e-fips-rhel5
Via 1.1 varnish
X-Powered-By PHP/5.3.13
X-Varnish 562862498
Headers sent
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language ro-ro,ro;q=0.8,en-us;q=0.6,en-gb;q=0.4,en;q=0.2
Host adgarage.ro
Origin http://sencha.local
Referer http://sencha.local/fisa-agenti/index.html
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101
Firefox/30.0
Note the Access-Controll-Allow header.
It is missing from the header container received from localhost
And here is my .htaccess file:
Header set Access-Control-Allow-Origin *
Header set Access-Control-Allow-Credentials: true
this file is the same on both servers.
I have the headers_module acitive on local machine.
Another thing I noticed is that response status from local is 301 moved Permanently while the response status received from remote server is 200 Ok
What I am missing?
Thank you!
I've identified the problem.
As discussed in this this topic headers were not sent because of the 301 Moved Permanently status.
My local requests were made to http://local.api/fa?ref.agent/... instead of http://local.api/fa/?ref.agent/... - notice the trailing slash missing after /fa in the first link.
Everything it's ok now.