I've integrated sleuth into my application gateway and the services behind it. The traces in Stackdriver (GKE) look good but the root-span is always named "/". For example:
The second span is also created by the gateway and has a much better name.
How can i configure sleuth in my gateway-service to use a different naming or fix whatever causes two spans?
EDIT1:
I created a minimal project with spring-gateway, sleuth and gcp and wrote a LoggingReporter to print all reported spans while having GCP auto-config working.
StackdriverHttpClientParser names spans based by the request uri. The second span is created by the TraceWebFilter based on a request with the full uri. the first span is created by the HttpClientBeanPostProcessor based on the uri "/".
I don't think this is a gcp issue. it is probably a problem with spring-gateway. Interestingly the TraceWebFilter span is created first, but the PostProcessor one is still the parent.
EDIT2: I created an issue in spring sleuth https://github.com/spring-cloud/spring-cloud-sleuth/issues/1535
I'm agreed with comment made by Marcin, the problem could be on Stackdriver and you can validate this by running a trace in your environment (offline) and also by be assured that the x-cloud-trace-context: TRACE_ID/SPAN_ID is formatted correctly, as per what I have seen there are three ways to do it and are mentioned here.
If the trace results successful by running it offline without changing anything then the problem is with stackdriver.
Related
I've searched the stack but didn't find an answer that helps my situation. We have two web apps on different sets of servers. Both do Active Directory authentication using the exact same standard code. And the target LDAP server is the same in all cases.
Using ctx As New PrincipalContext(ContextType.Domain) If ctx.ValidateCredentials(un_in, pw_in) Then...
However, in one case those two lines execute instantaneously, and the other there's a consistent 21 second delay (there's logging directly before and after these lines). And for the slow one, it's slow regardless of environment, i.e. on our dev/test/stage/prod servers.
We're at a loss as to what to check. Basic network connectivity checks show no delays, and plus this happens on 4 different servers. Connectivity to the domain controller, which as I understand it is how IIS would know which LDAP server to check possibly?. Thoughts?
In case anyone comes across this. The solution was to add a parameter,ContextOptions.Negotiate, to the code:
Using ctx As New PrincipalContext(ContextType.Domain)
If ctx.ValidateCredentials(un_in, pw_in, **ContextOptions.Negotiate**) Then
Something in the network environment changed that no one could identify. But adding this param removed the delay.
I'm wondering if anyone else has had this issue with Azure Front Door and the Azure Web Application Firewall and has a solution.
The WAF is blocking simple GET requests to our ASP.NET web application. The rule that is being triggered is DefaultRuleSet-1.0-SQLI-942440 SQL Comment Sequence Detected.
The only place that I can find an sql comment sequence is in the .AspNet.ApplicationCookie as per this truncated example: RZI5CL3Uk8cJjmX3B8S-q0ou--OO--bctU5sx8FhazvyvfAH7wH. If I remove the 2 dashes '--' in the cookie value, the request successfully gets through the firewall. As soon as I add them back the request gets blocked by the same firewall rule.
It seems that I have 2 options. Disable the rule (or change it from Block to Log) which I don't want to do, or change the .AspNet.ApplicationCookie value to ensure that it does not contain any text that would trigger a firewall rule. The cookie is generated by the Microsoft.Owin.Security.Cookies library and I'm not sure if I can change how it is generated.
I ran into same problem as well.
If you have a look to the cookie value: RZI5CL3Uk8cJjmX3B8S-q0ou--OO--bctU5sx8FhazvyvfAH7wH there are two -- which is the potentially dangerous SQL command that can comment out your SQL command that you're going to query. An attacker may run their command instead of your command - after commenting out your query.
But, obviously, this cookie won't run any query on the SQL side and we are sure about that. So we can create rule exclusions that won't run specific conditions.
Go to your WAF > Click Managed Rules on the left blade > Click manage exclusions on the top > and click add
In your case, adding this rule would be fine:
Match variable: Request cookie name
Operator: Starts With
Selector: .AspNet.ApplicationCookie
However, I use Asp.Net Core 3.1 and I use Asp.Net Core Identity. I encountered other issues as well, such as __RequestVerificationToken.
Here is my full list of exclusions. I hope it helps.
PS I think there is a glitch at the moment. If you have an IP restriction on your environment, such as UAT, because of these exclusions Web Application Firewall is by-passing the IP restriction and your UAT site becomes open to the public even if you have still custom IP restriction rule on your WAF.
I ran into something similar and blogged about it here: Front Door incomplete first request.
To test this I created a web application and put it behind the Front Door service. In that test application I iterate over all the properties of the HttpContext.HttpRequest and print them out. As far as I can see right now, there are two properties that have differences between a direct request and a request through Front Door. Both the AcceptTypes and the UserLanguages property are empty for Front Door requests, while they are absolutely filled in when directly accessing the test application.
I’m not quite sure what the reason is for the first Front Door request to be different from a direct request. Is it a bug? Is it intentional and if so, why? Or is it because Front Door is developed using a framework that doesn’t support these properties, having them be empty when being forwarded?
Unfortunately I didn't find a solution to the issue, but to answer the question if anyone else is experiencing this: I did experience something similar.
Seems that the cookie got corrupted , as I was comparing the fields that existed before vs a healthy cookie, my guess is maybe somewhere in the content of the field it is being interpreted as a truncate sql statement and probably triggering the rule. Still to determine if this is true and/or what cause it.
I ran into this issue but the token was being passed through via the request query rather than via a cookie. In case it might help someone, for the specified host I had to allow via a custom rule doing a regex match on the RequestUri, using the following regex (taken from the original managed rule):
:\/\\\\*!?|\\\\*\/|[';]--|--[\\\\s\\\\r\\\\n\\\\v\\\\f]|--[^-]*?-|[^\\u0026-]#.*?[\\\\s\\\\r\\\\n\\\\v\\\\f]|;?\\\\x00
When I set the domain in the dashboard to xxxxxx.com, where xxxxx is my domain, I am still unable to make API calls from the domain given.
The error I get when I attempt to make an API call is:
"Unauthorized. The request is not from an authorized source."
There is no issue with the code itself as it was working before I had set a specific domain. I've also ensured that the domain typed into the dashboard is correct.
Any help would be appreciated, will provide more information, if needed.
It takes a bit of time for the changes to take effect. Please wait a little while, then try again. If it still doesn't work, please report back.
Alternatively please note that you also need to add any subdomains you may be using. For example, if you add "here.com", you would also have to add "www.here.com" and "developer.here.com" if you wanted API calls to be accepted from these subdomains.
I need a help, I try to record a script of some application like http://in.musafir.com/ ,https://www.makemytrip.com/ etc but after recording started page is open but CSS not apply in that case I am unable to create script due to fields missing or disturbance.
I am not excluding CSS and other in JMeter proxy server page.
One another thing some application getting connection exception after used ApacheJMeterTemporaryRootCA (its apply in the case show the message) .
This all testing is done in home environment & company environment. And both places has same issue.
Please update me the solution of this issues.
JMeter HTTPS script recorder gives you option to exclude certain URL requests based on their type. You can add or remove these URL patterns in your HTTPS Test Script Recorder.
JMeter recording template by default excludes css. So if you want to record CSS requests then simply remove css from this section. Check screenshot for details.
Regarding Root Certificate, if you are getting a message like below then it is normal and expected.
Please read JMeter Official documentation for more details about HTTP Test Script Recorder.
I am using Spring MVC to create RESTful endpoints. I am using spring-test-mvc to test them at the unit/integration test level. I am now coming across this team's first attempt at implementing an endpoint using DELETE. This means the container needs to be setup to allow for DELETE (PUT will come shortly after). My research took me here:
http://www.codereye.com/2010/12/configure-tomcat-to-accept-http-put.html
I am technically using JBoss, but I have a feeling a Tomcat write-up will do just fine. Anyway, my problem is not at the container level.
I am trying to create a unit test to verify the most basic of 404. Let's say you try to delete a user calling /users/{id}. My test passes an invalid id, and I expect a 404 to return. It gives a 405. This makes sense when DELETE is not supported. Following the instructions in the link above, I should add some entries to the web.xml. I did so in main and test. Both still gave me the 405.
How would I setup spring-test-mvc to grab these new http-method types out of the web.xml or some other location? My research hasn't come up with anything other than DELETE isn't initially supported.
Thanks
Dustin
Spring-test-mvc does support DELETE(and PUT), I have used it with a DELETE based method, it is true that you need to add HiddenHttpMethodFilter filter in web.xml for DELETE http method to work within your application, however spring-test-mvc does not look at the filter, it works from DispatcherServlet down, here is one of the samples that works for me:
mockMvc.perform(delete("/members/1").contentType(MediaType.APPLICATION_JSON))
.andExpect(status().isOk());
The error you are seeing I feel could be more related to the content-type or accept headers, that is where I have seen 405 being returned, you may be able to change your log level to debug or trace and see what else shows up.