My Http protocal, where I am setting disableFollowRedirects. However there is one get call I am making for which I want the execution to follow redirect. Can we do that ? I tried disableProtocolChecks but it isn't working
.baseUrl(brokerHost)
.acceptHeader("text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8") // Here are the common headers
.acceptEncodingHeader("gzip, deflate")
.acceptLanguageHeader("en-US,en;q=0.5")
.upgradeInsecureRequestsHeader("1")
.userAgentHeader("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36")
.disableFollowRedirect
For this request I want to execution to follow redirects
.exec(http("Post SAML request to IDP")
.post(/authentication/SSOPOST/")
.check(status.is(302))
.check(header("Location").saveAs("redirecturl"))
)
No, it's not currently (as of gatling 3.4) possible, neither one way (disable globally and re-enable locally) or the other (enable globally and disable locally). There's no control over followRedirect behavior at the request level.
Now, could you please explain why you would be able to do that?
Usually, people want to disable followRedirect because they think they should capture the Location response header in the redirect response so they can capture data from the landing page url.
This is wrong. Instead, they should let followRedirect enabled and use the currentLocation and currentLocationRegex checks.
Actually, we're considering removing the disableFollowRedirect option, unless we really have a compelling reason not to do so.
Related
How can I get Https or Http in the backend code of a DNN module?
Currently, I have got this code, but I need the protocol (https:// or http://)
PortalSettings.Current.PortalAlias.HTTPAlias + PortalSettings.HomeDirectory + PortalSettings.LogoFile;
You can maybe use this to check if the current tab has https enabled (to check the request itself you can use Request.IsSecureConnection)
PortalSettings.ActiveTab.IsSecure
And/or
PortalSettings.SSLEnabled;
PortalSettings.SSLEnforced;
PortalSettings.SSLURL;
If you want it for the current URL, you can use the regular .NET API's as well.
HttpContext.Current.Request.Url.Scheme
That will return http or https based on the current request URL. Its the fastest way that I'm aware of to do this.
For Microsoft OAuth 2.0 auth code grant, we have encountered an issue with scopes.
When we requestion only the User.Read scope, our client is asked to grant permission to us for Sign you in and read your profile and Access your data anytime. Where we didn't state we need offline_access scope.
This is only happening after Microsoft switched to new permission grant interface. Have someone else encounter the same issue or we did something wrong?
The response_type we pass in is code only.
I have double checked, the application we registered is under https://apps.dev.microsoft.com.
The URL we use for authorizing is following.
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
As I said earlier, the only scope we pass in through query was User.Read.
Edit 3
Request URL: (I have removed client id.)
https://login.microsoftonline.com:443/common/oauth2/v2.0/authorize?client_id={client_id}&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A19974%2Fapi%2Fv1%2Fmicrosoft%2Foauth2%2Fsession&response_mode=form_post&scope=User.Read&state=1527572151-IIZ0D&nonce=1527572151-IIZ0D&prompt=consent&domain_hint=organizations
Response that logged with fiddler:
POST http://localhost:19974/api/v1/microsoft/oauth2/session HTTP/1.1
Host: localhost:19974
Connection: keep-alive
Content-Length: 798
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: null
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en,en-NZ;q=0.9,zh-TW;q=0.8,zh;q=0.7,zh-CN;q=0.6
DNT: 1
code=OAQABAAIAAADX8GCi6Js6SK82TsD2Pb7rUmGhJoHUB3devvTffqTlhRhg9XZ202zgEA8B37CzgkeLNVBc4FFstw3sTjNmYhKCYLE_jcl7KeCrtYgPVFYOKUuazv_B3vHKIM8ttwIzOlV_3GL4vqxPgjvXbWUdas5Sj9Z1X9fEBB63Wa1Ig0AnisnHk6qagIimFEPApYx473RzgIve2erM3r5fnX5Q0L1-pHppSFUJoWop6MPTkUh-umPzuXQgB280rHyUds3odS6_cJP6SbI70aLNOqHV_AnaV_VUZqQ6hLfBZMVKFMYMg_r_harPOU5EE2gf2d15FIKMsmjPRTR2vryaJRyg0TblF_jr-kWyeURwpbkPzsU6r3avEqM6dfTqhhASoXB4VmeZ2zw75pZgK4v8cfcd3J_tIpFRjcEY1TqPz5E3QrYQGfFSeBEEbjwqvj2X5_4VBvve7ABdrt3OCjid8E_837mLX-Fv5t3nk_nfnV0SY6XrFQQmoPClyqSyn44FTv_WFY7Af74SfeBrWDYSSiTuwphEmVTeT6U2R4Rs4wR8G0uHW2L53U-4UbkODd-_-JZYIahAohDAF-8TaguUwb4mOK497wsFOkgpmYz-np4MX3sTweSLmn6bAOy9Y91E3o4fuERzX9m9N_HBt64cv6k8JROKJqs6cx1Gb9EoYCRLCn2ihWi_crZh2PH5LACMCLWYgH0gAA&state=1527572151-IIZ0D&session_state=1faeaab9-0f00-45cb-a776-356463a54684
Edit 4
Today, I have done few more testing while upgrading project to .Net Core 2.1. I have notice that even though from interface it is confirming Access your data anytime, but when I use code to exchange access token, it doesn't contain refresh token.
The other thing I have notice is, when I pass scope as User.Read, and when I exchange access token, the scope came back as: User.Read User.ReadBasic.All. This is a bit of inconsistent, but not big issue.
It’s not currently possible to remove the offline_access scope from the initial consent screen when using the v2 endpoint with an AAD account. When requesting tokens the offline_access scope is still explicitly requested though.
This is an issue which is in a planned state on Azure Active Directory suggestions and feedback site.
Admin's post (Oct 2, 2018) mentions a plan to fix this "within the next 3 months".
Cuase:
For v1 endpoint, the scope isstatically configured in AAD App registration. If you have add access user's data anytime permission, you will also get the offline_access scope in your request.
Solution:
If you don't want to let user have offline_access permission, you can unpick up the Access user's data anytime permission in Microsoft Graph delegated permissions.
More about offline_access :
offline_access is one of OpenID permissions. It's name is offline_access and it's Display String in v1 endpoint is Access user's data anytime.You can see more details about this permission in this documentation.
This error has perplexed me. I have been working on this application for a year now and one of the most original parts of it just started failing for no apparent reason. I haven't made any configuration changes or changes in and around the area which is failing, so it is baffling me.
Requirement
In my SPA, click on a button and the JSON model associated to that button is sent to the server to be saved.
Implementation
return $resource('/api/audits/:auditId/auditAnswers', { auditId: auditId, auditAnswer: auditAnswer }).save(auditAnswer);
This in turn is handled by WebAPI 2.0
[Route("api/audits/{auditId}/auditAnswers")]
[HttpPost]
public ServiceResult SaveAuditAnswerByAudit(HttpRequestMessage request, Guid auditId, [FromBody]AuditAnswerModel auditAnswer)
{ ... }
Issue
This worked for a good year without issue. Now when I test in Firefox 46.0.1 hosted in IIS Express, only about 1 in 5 attempts actually reaches the WebAPI method. No other post seems to reach WebAPI at all.
The error occurs as soon as I attempt the post, so it does not seem like it's timing out, either.
Firefox reports
Accept application/json, text/plain, */*
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Content-Length 348
Content-Type application/json;charset=utf-8
Host localhost:61032
Referer http://localhost:61032/QAT/Audits/f3fa490d-6324-4227-b8fa-a6be4d33dd82
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Also, no HTTP status code is reported.
The error Callback for $resource is called and the response object contains:
data null
status 0
statusText ""
I have come across this once already and fixed it by not posting the entire JSON to WebAPI, but there are times I need to do this and consider it the correct way to do so.
Thinking it may be browser related I have restarted the browser, computer, cleared cached, and none of these methods resolved the issue. However, using a different browser such as Chrome does not encounter this issue (yet).
The fact that it works "eventually" (after about 5 attempt) is most concerning to me.
Question
Is this a known issue? Is it my fault? Is there something I can do to fix it?
On server side is there any way to detect that particular request to API came from mobile device (from mobile app)?
I know about user agent sniffing but I dont like this aproach from few enough reasons not to implement it.
I also know I could add some flag to request when it comes from my mobile app, but this seems bit dirty as well.
Are there actually any 'proper' ways to do it?
I guess it doesn't change much but my backend is in node.js.
Greetings, thanks!
Tom
The general answer is no. You get a header / message from a device. All you know about the device is in the header and the device can write what it wants in it. If you are talking about http requests (which is indicated by agent lookup) you can look at a header here:
All you can do "reliable" is to look for the user agent. In my case it is Mozilla Firefox on Linux. But I could fake it if I want.
Host: somesite.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://somesite.org/index.php?page=2
Cookie: rteStatus=rte;
Cache-Control: max-age=0
Maybe you can get some informations from the referer if it is some chromium-mobile site or you can have a look at Accept and Accept-Enconding, maybe some mobile browsers accept different stuff. But there is no reliable way to determine the device but by its user Agent via header.
An other approach is to look if the request comes from an IP known as 3G or 4G pool. But this would just work if the requests is not coming via WLAN / WIFI. And I am not sure if a list of 3G / 4G IP address pools exists.
You can use UserAgent string for detecting. Below code in C#.
public bool IsMobileDevice(HttpRequest r){
String userAgetnt = r.UserAgent;
String deviceName = "Android|webOS|iPhone|iPad|iPod|BlackBerry|IEMobile|Opera Mini";
return Regex.IsMatch (r.UserAgent, deviceName);
}
To detect if request came from mobile app, you must pass Accept:application/json in each request, then in your controller detect if request expects or wants json, if request expects json then return json response otherwise do what you want.
In the APP Engine API, it is mentioned that, if the request comes with "Accept-Encoding" set, then it will automatically compress the response.
But when I look at the request, the header is not there. but at the browser, it is set. when I try to explicitly set the header(with JQuery ajax function), there is a message:
Refused to set unsafe header "Accept-Encoding"
But this situation is not occurring when working in local host - request has the "Accept-Encoding" header. this happens only after publishing. but not allowing to set the "Accept-Encoding" explicitly happens always.
I searched everywhere, but couldn't find a explanation to the problem. It would be really helpful if someone can explain...
You have two different problems:
App Engine does not compress reply. GAE uses a number of factors to determine if response needs to be compressed. It takes content type and user agent into account when deciding. See the answer by Nick Johnson (from GAE team).
jQuery refuses to set "Accept-Encoding" header. Note that this is a jQuery issue and has nothing to do with GAE. See this: Is it possible to force jQuery to make AJAX calls for URLs with gzip/deflate enabled?
I have a similar problem as in the HTTPRequest header, "Accept-Encoding" is null. As GAE has explained it looks for Accept-Encoding and User-Agent headers, if it wants to compress. but in my case there is no way the GAE can recognize whether to compress.
From the browser, then header is set, but in the request header, it is not.