I have a server running over Google App Engine.
I am viewing my server's request-log via the console.
They are located under Google Cloud Platform --> Stackdriver Logging --> Logs.
I would like to view the arguments of a POST-Request.
With a GET-Request it is easy, as they are visible in the title of the entry.
They are also viable in the body of the entry, under protoPayload --> resource.
With a POST-Request, however, they are nowhere to be found.
Here are my options:
metadata
protoPayload
insertId
log
httpRequest
operation
None of these options seem to contain the arguments of the request.
From this answer, I understand that they should be within the request-body.
How can I find them within GAE logs?
post request data isn't shown in request logs.
In your app, you must explicitly log it
logging.log(myRequest.PostData)
Edit: just be careful logging sensitive customer information.
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 a static website on an Azure web server/portal that holds our company's documentation. Recently, I've been making changes to our code that sets our cookies to ensure that they comply with the browser SameSite requirement as explained here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
I've been able to fix all my scripts that create my cookies, but while testing them today, I see that there's this cookie message that still appears in my FireFox console:
Cookie “ARRAffinity” will be soon rejected because it has the
“sameSite” attribute set to “none” or an invalid value, without the
“secure” attribute. To know more about the “sameSite“ attribute, read
https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite
This message only appears when I clear the cache from the site and load the page. Once I reload the page a second time or load any other page after that, I no longer see the message.
I believe this ARRAffinity cookie technically comes from Azure's Application Insights (AI)--or something on the Azure web server. It doesn't appear in our javascript files at all. We use AI for our analytics. Here is the code snippet that we got from Azure about two years ago. It gets injected into the header of each .htm page on our site:
var appInsights=window.appInsights||function(a){
function b(a){c[a]=function(){var b=arguments;c.queue.push(function(){c[a].apply(c,b)})}}var c={config:a},d=document,e=window;setTimeout(function(){var b=d.createElement("script");b.src=a.url||"https://az416426.vo.msecnd.net/scripts/a/ai.0.js",d.getElementsByTagName("script")[0].parentNode.appendChild(b)});try{c.cookie=d.cookie}catch(a){}c.queue=[];for(var f=["Event","Exception","Metric","PageView","Trace","Dependency"];f.length;)b("track"+f.pop());if(b("setAuthenticatedUserContext"),b("clearAuthenticatedUserContext"),b("startTrackEvent"),b("stopTrackEvent"),b("startTrackPage"),b("stopTrackPage"),b("flush"),!a.disableExceptionTracking){f="onerror",b("_"+f);var g=e[f];e[f]=function(a,b,d,e,h){var i=g&&g(a,b,d,e,h);return!0!==i&&c["_"+f](a,b,d,e,h),i}}return c
}({
instrumentationKey:"<The Key>"
});
window.appInsights=appInsights,appInsights.queue&&0===appInsights.queue.length&&appInsights.trackPageView();
(Note that <The Key> in the snippet above is actually a unique multi-character string that Azure gave us when we set up and configured the AI resource. I removed it here for privacy.)
I've since revisited the site where I got that code, but the snippet has changed to something newer:
https://learn.microsoft.com/en-us/azure/azure-monitor/app/javascript#snippet-based-setup
I'm not sure if I need to do anything to fix this.
Does ARRAffinity cookie come from some server-side script that Microsoft creates?
Do I need to do anything on my side to resolve this console message? If so, what?
ARRAffinity cookie is automatically created by Azure. You can turn it off by going to Configuration --> General Settings and then click on Off in the App Service as shown below.
As your's is a static website, i don't think this would be an issue. In fact, it is recommenced to turn ARR Affinity to Off for any Cloud Native applications.
When ARR Affinity is turned off, all the App Service instances (in a load balanced env) will be used effectively.
If ARR Affinity is turned on, all the requests for a given session will be sent to the same server irrespective of the load on it.
By default, the setting is on to to support legacy applications that needs Session stickiness.
Linkedin has a whole slew of fields to pull them with their API. But they say they want you to apply for something before you can request the fields (see a screenshot below). My question is, can I query those fields during development to test my app? Now Linkein returns error, if I try to request them. And Linkedin doesn't say anything about it in their API docs.
InternalOAuthError: Failed to obtain request token
Here is a screenshot.
I still don't know the answer whether I can test the behavior during development.
However, with trial and error method I found what permissions generate error in Linkedin. Lol thing is that you can request fields from those permissions just fine (no error throws), but cannot request permissions.
Fields from forbidden permissions (do not throw even if permissions are omitted in a request):
['languages', 'date-of-birth', 'phone-numbers', 'im-accounts'],
Forbidden permissions that throw:
['r_fullprofile', 'r_contactinfo'],
when I moved to AMP, the Google Tag Manager stopped to working.
The problem occurs every time when I open my AMPed page, I can see some errors in browser console, e.g.
First error:
https://www.googletagmanager.com/amp.json?id=MY_GTM_TAG>m.url=MY_HTTP_URL
(403)
Second error:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '' is therefore not allowed access. The response had HTTP status code 403. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
In my class that extends WebMvcConfigurerAdapter I overwritten the method addCorsMappings like this:
#Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")
.allowedOrigins("*")
.allowedHeaders("*")
.allowCredentials(true);
};
But it still doesn't work (this method is executed on startup, I checked it). Do you have any ideas / tips why?
EDIT 1 (22.12.2016):
Q: How are you loading tag manager? Are you using the AMP version of the script? (#Jim Jeffries)
A: Yes, in <head> I included the following piece of code:
<script async custom-element="amp-analytics" src="https://cdn.ampproject.org/v0/amp-analytics-0.1.js"></script>
and in <body> there is:
<amp-analytics config="https://www.googletagmanager.com/amp.json?id=${googleTagId}>m.url=SOURCE_URL" data-credentials="include"></amp-analytics>
I was having the same issue and it turns out you can't use your old GTM "Web" container for this so you'll have to create a specific AMP Container.
As per Google's instructions found here:
Create an AMP container
Tag Manager features an AMP container type. Create a new AMP container for your project:
On the Accounts screen, click More Actions (More) for the account
you'd like to use. Select Create Container.
Name the container. Use a descriptive name, e.g. "example.com - news - AMP".
Under "Where to Use Container", select AMP.
Click "Create".
Based from this thread, maybe you are doing an XMLHttpRequest to a different domain than your page is on. So the browser is blocking it as it usually allows a request in the same origin for security reasons. You need to do something different when you want to do a cross-domain request. A tutorial about how to achieve that is Using CORS.
*When you are using postman they are not restricted by this policy. Quoted from Cross-Origin XMLHttpRequest:*
Regular web pages can use the XMLHttpRequest object to send and receive data from remote servers, but they're limited by the same origin policy. Extensions aren't so limited. An extension can talk to remote servers outside of its origin, as long as it first requests cross-origin permissions.
Also based from this forum, the app must authenticate as a full admin and POST the desired CORS configuration to /rest/system/config.
When I open the details window on any of my API Proxies using the APIGee Developer Dashboard, I get two error messages
Error while fetching object: No server entry found with ID long token goes here
and
Server Error: No server entry found with ID same long token goes here
The page still seems to function partially, but this prevents me from seeing my API proxy deployments and proxy information, or from tracing calls to the API.
I can't figure out what triggered this error - I don't see any recent config changes and the API proxy and the endpoint services are up and running. There's no reference to 'Server Entry' anywhere on the config page or in the help, which makes it hard to know where to start when fixing this.
Please see here: http://status.apigee.com/
This could be related to the platform release in flight.
You can subscribe to this for future updates too.
If the issue still persists, do raise a support ticket http://apigee.com/about/support/request-support