When hasura has a remote schema error (such as a timeout) it shares all the request details to the client calling it including any internal forwarded header files which can include shared secrets.
Is there a way to prevent it from doing this?
Looks like it has to do with the HASURA_GRAPHQL_DEV_MODE configuration in the docker file, setting this to 'false' or not at all fixes the issue and masks the error.
Related
We are using AWS Amplify for our NextJS web app and keep receiving error when ever I try to load the application once deployed to Amplify. Locally there is no issue.
I am using Amplify's default Auth configuration, with basic email and password auth. It looks like it could be related to the Amplify cookie being set in the header but I cannot find any documentation within AWS to prevent this or reduce the amount of information passed with the header. Any help would be appreciated.
I have faced the same issue and was able to solve it. Here's how -
Identify the CloudFront Distribution ID for your app. You can find it in the Deploy logs of your app build console.
Search & open that particular CF Distribution and go to the Behaviours tab.
Select the Default behaviour (5th one in my case) and hit Edit.
Scroll down to the Cache key and origin requests section.
Here you will find settings to control what's included in the headers of the request that goes to the server. In my case, I didn't need any Cookies so I chose None, and it solved the issue for me.
In your case, you can do the same or pick what all info needs to be in the headers.
Check to see if there are any unnecessary cookies for that domain.
I was getting this error (on a site I don't own). I took a look at the request headers and found a very large number of cookies (several dozen) for the site's domain. I cleaned up the cookies which seemed non-critical and the error went away.
As the error implies, the size of the entire request header section is above 8192 bytes. Request headers include the accept headers, the user agent, the cookies, etc. and all combined can get rather large. Large headers look malicious to some WAFs. I once had a single user having trouble with our site. Turns out they were a polyglot and had configured their browser to accept several dozen languages causing their accept-language header to be suspiciously long, and the WAF refused to proxy the request.
I faced the same issue using Nextjs, amplify and an external Auth provider.
The problem is that AWS S3 service has a request header maximum allowed size of 8192 bytes, so when ever you try to access the static generated pages of Nextjs it returns that error. This has already been asked here
In my case, I was using an external Auth provider and I was able to solve the issue configuring the cookies only for the '/api/' path. That way the Auth cookies are sent only to the Nextjs api endpoints, so your request header is lighter whenever you try to get the static pages.
I have an Angular web app running on Cloud Run (nginx webserver) (more info here) from which I want to get access token from the GCP metadata server. I have tried to make a call to https://metadata.google.internal ( using curl from Cloud Shell) but the connection was rejected. Calls to HTTP are working well.
When I make the call from my app (which is loaded over https) to the metadata server over HTTP - logically I get a mixed content error. When trying to access the metadata server over HTTPS - I am getting error 504 Gateway timeout, I assume due to the reason that the metadata server refuses the calls on HTTPS.
I will really appreciate any idea of how to solve this issue.
The URL endpoint metadata.google.internal is only accessible from inside the instance (Cloud Run). This endpoint is not accessible outside of the instance such as via an HTTP or HTTPS call. A clue is the TLD (Top Level Domain) internal.
If you want to access this endpoint remotely via a web browser, you will need to make a request from the browser to Cloud Run (an endpoint in your code) which then makes the internal request to the metadata server and returns the response to the client.
I am trying unsuccessfully to publish from SBT into a Nexus repository running on my network. Attempts to publish fail with a forbidden error
If I look at the Nexus side of things with trace debugging on, I can see the request, but there is no Authorization header in the request.
This is my build.sbt
And this is my credentials file
I have used curl to see what the Realm should be, which hopefully I have reflected in my credentials file
But nothing I do seems to get the Authorization header in the PUT request. Is there something obvious I am missing? I feel like I am spinning my wheels.
Thanks for any help
This did end up being how I had set up my files. My build.sbt file was fine. However, in my credentials, my Host value contains a port, which was confusing the IvyAuthenticator. I ended up seeing this error message when running through sbt shell in IntelliJ
My issue was that, in my credentials file, my host ended with the ":8081" value, and it looks like IvyAuthenticator was using the host name without the port information.
So, after updating my credentials file, so that the host value was just the machine name without any port details, my publish succeeded.
I use nginx as my reverse proxy server to fetch image from the file server, which is also a web server.
It works well. but I want add permission check based on the url before send request to my file server. If has permission, just forwarding to my file server, or else just return 404.
BTW, I can't add the check in my file server for some reason.
I think I got the answer.
The module "http_auth_request_module" is what I want. https://www.nginx.com/resources/admin-guide/restricting-access-auth-request/
Am trying to use asterisk by posting via http to get the peers, and i keep getting permission denied and then the remote server is not accessible or disconnected, though the login action is working fine and the manager.conf persimission is set correct to allow read and write.
Here is the request:
http://[ServerName]:8088/asterisk/mxml?action=Sippeers&actionid=SipPeersAction&SuppressEvents=True
I found the problem. It turns out that one of the extensions/trunks set inside the SIP file is causing reading the peers to crash, so the users is disconnected, and that's why you get permission denied afterward. So first comment all the extensions inside the sip file then try to run the sippeers actions, make sure it works, then start enabling extension gradually until you identify the extension that is causing the problem.
May be you are using a custom code (http client) instead of browser and your client is not handling cookies properly! after the login request you must get cookie from asterisk response and save it for further use.
read more about ajam here
http://www.voip-info.org/wiki/index.php?page_id=3578
and here is php based example that how to use cookies in custom request (http client)
http://coderscult.com/php/php-curl/2008/05/20/php-curl-cookies-example/