I created a simple page using the code provided by this page (the first sample):
http://www.dotnetopenauth.net/developers/code-snippets/programmatic-openid-relying-party/
But I can't seem to get it to work, I can redirect to the provider but when the provider redirects back to my page, I get error 500, "The request was rejected by the HTTP filter".
I already checked ISAPI filters which I have none.
I've never seen that error before. Is this page hosted by the Visual Studio Personal Web Server (Casini) or IIS? I suspect you have an HTTP filter installed in IIS (or perhaps your web.config file) that is rejecting the incoming message for some reason.
Note that you need to turn off ASP.NET's default page request validation on any page that can receive an OpenID authentication response because those responses can include character sequences that look like HTML/Javascript-injection attacks but in fact is harmless.
I discovered that I'm using Isa in the server, so I just followed this instructions to get it working.
http://blog.brianfarnhill.com/2009/02/19/sharepoint-gets-the-error-the-request-was-rejected-by-the-http-filter/
Related
We got the following problem:
I am currently developing a web server implementing a specific API. The association behind that API provided specific test cases I'm using to test my implementation.
One of the test cases is:
5.3.2.12 Robustness, large resource ID
This test confirms correct error handling when sending a HTTP request with a very long location ID as URL parameter.
The url its calling looks something like this:
https://localhost:443/api/v2/functions/be13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005
Basically the tests checks, if my server responds with the correct error code if the URL is too long. (At the time of writing it is testing for Errorcode 405, but I already asked them if it shouldn't be 414)
I'm developing the server in Asp.Net 6 and it always returns Bad Request 400 in the testcase.
I don't seem to find a place to change the handling for this behaviour and I am not even sure, if I can, or if the IIS is blocking the request even before it reaches my server. I activated logging in IIS, but the request does not show in the logfile in inetpub/logs/LogFiles.
My question would be, if it is possible to tell IIS to return a different error code in this case, or if it is even possible to handle the error in my application.
What I tried:
Activating IIS Logs to see if the request is even passed to my site. (It did not)
Tried adding Filters to my Controller to see if I can catch an Exception
Checked, if Development Error Sites are called.
Breakpoints in existing middlewares are not reached.
EDIT:
I am now pretty sure now, that the request never reaches my application.
It is possible to reproduce the error by using the default site the IIS generates on windows. Just copy the whole path from above into a browser with the host http://localhost will also just produce the error 400
EDIT 2:
As #YurongDai pointed out, I tried activating failed request tracing for my IIS Site. I used the default path \logs\FailedReqLogFiles.
The folder was created, but no file is written, when I'm opening the URL above in my browser.
IIS Error 400 occurs when the server is unable to process a request sent to a web server. The most common cause of Bad Request error 400 is an invalid URL, but it can happen for other reasons as well. To resolve IIS Error 400, first make sure that you have entered the URL correctly, typos or disallowed characters in the URL are the most common causes of Bad Request errors. If the error persists after verifying the URL, please clear your browser's cache, DNS cache, and cookies and try again.
Clear your browser's cookies.
Clear your browser's cache.
Clear your DNS cache.(Execute the following command in the command prompt window: ipconfig /flushdns)
one of my old project/app was working fine for years, very recently client report that app does not working any longer due to API response issue.
it's just a get request to an API with some parameters..
till date (before issues occurs) it returns following response:
,,3,1669179307,0,
but recently it shows following response: (note nothing is changed in the source php/code files since project start)
<html><title>You are being redirected...</title>
<noscript>Javascript is required. Please enable javascript before you are allowed to see this page.</noscript>
<script>var s={},u,c,U,r,i,l=0,a,e=eval,w=String.fromCharCode,sucuri_cloudproxy_js='',S='bT0nP2RUNCcuc3Vic3RyKDMsIDEpICsgJycgKyAKJz9iVGYnLnN1YnN0cigzLCAxKSArICcnICsgCidIcExjJy5zdWJzdHIoMywgMSkgK1N0cmluZy5mcm9tQ2hhckNvZGUoNTYpICsgJ3FAYycuY2hhckF0KDIpKyAnJyArIAonNycgKyAgICcnICsgClN0cmluZy5mcm9tQ2hhckNvZGUoMHg2MykgKyAgJycgKycnKyIyc3VjdXIiLmNoYXJBdCgwKSsiYyIgKyAiNHNlYyIuc3Vic3RyKDAsMSkgKyAiZW0iLmNoYXJBdCgwKSArICAnJyArIAoiM2MiLmNoYXJBdCgwKSArICIiICtTdHJpbmcuZnJvbUNoYXJDb2RlKDk3KSArICJlIi5zbGljZSgwLDEpICsgICcnICsnZCcgKyAgJ0RiJy5zbGljZSgxLDIpKyAnJyArJycrJ3hJMScuY2hhckF0KDIpK1N0cmluZy5mcm9tQ2hhckNvZGUoMHgzMSkgKyAncTAwJy5jaGFyQXQoMikrU3RyaW5nLmZyb21DaGFyQ29kZSgweDYzKSArICIiICsnSHVIZScuc3Vic3RyKDMsIDEpICsiN3N1Ii5zbGljZSgwLDEpICsgIjhzdSIuc2xpY2UoMCwxKSArICdjJyArICAiZHN1Y3VyIi5jaGFyQXQoMCkrJ2EnICsgICIiICsiY3N1Y3VyIi5jaGFyQXQoMCkrImRzZWMiLnN1YnN0cigwLDEpICsgU3RyaW5nLmZyb21DaGFyQ29kZSg0OSkgKyAgJycgKyAKU3RyaW5nLmZyb21DaGFyQ29kZSgweDMzKSArICAnJyArJycrJ2QnICsgICAnJyArIAonMScgKyAgJyc7ZG9jdW1lbnQuY29va2llPSdzdXMnLmNoYXJBdCgyKSsndXN1YycuY2hhckF0KDApKyAnYycrJ3UnLmNoYXJBdCgwKSsncnN1Y3VyaScuY2hhckF0KDApICsgJ2knKycnKydzdWN1cmlfJy5jaGFyQXQoNikrJ2MnKycnKydsc3VjdXJpJy5jaGFyQXQoMCkgKyAnb3N1Jy5jaGFyQXQoMCkgKyd1JysnZHMnLmNoYXJBdCgwKSsnc3AnLmNoYXJBdCgxKSsncnN1Y3UnLmNoYXJBdCgwKSAgKydvJysneHN1Y3VyJy5jaGFyQXQoMCkrICd5Jysnc3VjdXJfJy5jaGFyQXQoNSkgKyAnc3V1Jy5jaGFyQXQoMikrJ3UnKydpJysnJysnZHN1Y3VyJy5jaGFyQXQoMCkrICdfc3UnLmNoYXJBdCgwKSArJzQnKycnKydzdWN1cmMnLmNoYXJBdCg1KSArICc2c3VjJy5jaGFyQXQoMCkrICcwc3VjdXInLmNoYXJBdCgwKSsgJ3N1Y3VyaTUnLmNoYXJBdCg2KSsnc3U0Jy5jaGFyQXQoMikrJ3N1Y3VyNCcuY2hhckF0KDUpICsgJ2YnKycyc3VjdXJpJy5jaGFyQXQoMCkgKyAiPSIgKyBtICsgJztwYXRoPS87bWF4LWFnZT04NjQwMCc7IGxvY2F0aW9uLnJlbG9hZCgpOw==';L=S.length;U=0;r='';var A='ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/';for(u=0;u<64;u++){s[A.charAt(u)]=u;}for(i=0;i<L;i++){c=s[S.charAt(i)];U=(U<<6)+c;l+=6;while(l>=8){((a=(U>>>(l-=8))&0xff)||(i<(L-2)))&&(r+=w(a));}}e(r);</script></html>
here is curl screenshot:
And here is the postman screenshot:
and when i check the URL in browser it shows the expected result, though when i check the devtool (network tab), it looks like page is loaded two times.. 1st one provide error (HTML/js) response (read marked) 2nd one provide the expected response (green marked), so, it looks like when it's called directly by curl/postman/c#... fails.. but as browser can do redirect it passed.
here is the browser screenshot:
i am sorry, i added several screenshot to give better idea what is happening.
and here is the URL in question:
https://simpleclienttracking.com/membershipmanager/remotelogvisit.php?locID=1&orgID=1&deptID=1&barcode=8346420
now my question, is how can i use the API code/file to get the direct response as i was getting earlier? do i need to pass any header? update/modify server htaccess file or what?
To test the error in deep, i have tried another URL from another hosting provider, in that case i am passing post request to an URL, and this server response slightly different thing, but looks like core is same, redirect!
here is the response from new/another server:
<script>document.cookie = "humans_21909=1"; document.location.reload(true)</script>
so, it's looks like hosting providers has applied some kind of security for direct URL access?
thanks in advance for any upcoming help
best regards
I am trying to setup a social login for my site.
Here is what I did:
I created credentials on google and have both ClientID and Secret
In default MVC app, in App_Start Startup.Auth.cs I uncommented
app.UseGoogleAuthentication()* method, so it looks like this:
Build solution!
Made sure authorized JavaScript origins and Redirect url are correct. And other things that are needed on console.cloud.google.com are done. Including activation of Google+ API
Eventually Google authentication button should appear in _ExternalLoginsListPartial partial view. But as I can see I have 0 login providers still. And not sure why, and what can I do about it?
var loginProviders = Context.GetOwinContext().Authentication.GetExternalAuthenticationTypes();
//loginProviders.Count() here returns 0
Tried researching, but most are saying that you forgot to build, or restart the server. Tried that but nothing changed.
As last resort, I tried following a tutorial https://youtu.be/WsRyvWvo4EI?t=9m47s
I did everything as shown there, I should be able to reach api/Account/ExternalLogins?returnUrl=%2F&generateState=true url, and receive callback URL from Google.
But I got stuck with same HTTP404 error at 9:50
To answer my question, everything turns out to be fine.
All I had to do was just to give it some time.
After couple of hours, Google provider appeared on the page.
For future readers - if met with 404 in this case, another possibility is an active filtering rule against query strings in IIS. One of the commonly copy-pasted rules aiming to block SQL injection requests scans the query string for open (to catch OPEN cursor). Your OAuth request probably contains this word in the scopes section (data you want to pull from the Google profile)
IIS -> Request Filtering
Switch to the tab "Rules"
Inspect and remove any suspicious active filters there
History: I have a tiny app that has lived on a linux web server for a while: html5/javascript/perl cgi scripts. There is a sort of third party middle ware called Siteminder from CA that provides SSO services and it works fine. In my case on the linux box there is a dir in the DOCROOT that holds the Public facing html, js & perl cgi scripts. There is a different dir where the pages and scriots for the authorized content sits. Siteminder is configured to be aware of this auth-dir and the request paths that contain that auth-dir element.
Siteminder is tied into Apache and observes the request stream and when it sees a request with a path element that it cares about it holds the in-bound request; redirects the visitor to a branded auth page; deals with the auth flow and then, if authenticated, sends the original request on through. In this case the auth is tied to an AD group. Again, this works. My pages and code are totally unaware of the existence of Siteminder.
For reasons above my paygrade it has been decided to move the content from the linux box to an IIS server. Convert everything to C# .Net MVC. I am NOT a windows person but this is what is in my plate at the moment.
Our local Siteminder experts tell me that SM works exactly the same under IIS as linux. That once I convert my code that it doesn't need to be aware of SM either... yet something is not working.
In my case, due to user interaction a modal popup appears in the Public section (HomeController) that holds a small form. Clicking the submit button triggers a jQuery GET (I've also tried PUT, POST and a redirect) action to a method in the AuthController, a la:
$.get({
'url': "/Auth/AddNewData",
'contentType': "application/x-www-form-urlencoded; charset=UTF-8",
'dataType': "json",
'traditional': true,
'data': {
'thing': myThing,
'otherThing': myOtherThing
}
}).done(function(data, textStatus, jqXhr) {
console.log("it worked");
}).fail(function(jqXhr, textStatus, errorThrown) {
console.dir(jqXhr);
console.log(textStatus);
console.log(errorThrown);
});
I am aware that there are .Net ways of stating the target url, please bear with me.
What I expect to happen is that if the visitor does not have the auth session cookie that Siteminder sets then they should be redirected to the SM auth flow and once authorized have this request complete.
Instead, what happens is that:
I use the get method: it fires and I get a 302 "Object Moved" response.
if I use the post method: it fires and I get a 200 Ok response but the returned payload is a small amount of html from SM saying that if I am not redirected to my destination shortly to press the button included in the form in that html. The jQuery fail promis fires though because it is expecting a JSON result, not html.
if I use put nothing happens.
I comment out my jQuery ajax call and just use a "location" redirect then SM will put up its challenge page; I can log in; and, the triggering request will be "continued" into a loop of length 3: it calls the page and fails with a 302 that seems to send the request back to SM where it is sent back to the target address to get a 302 then back to Sm then back to the target but it generates a 404 message.
I am deep in the weeds here. Advice would be wonderful
Oh, PS: running this in debug mode on my desktop (no SM) works. Running the Release version on the IIS dev server with SM is what fails.
EDIT
More info: after some additional siteminder config I started getting CORS violation messages. I am setting CORS headers now but that changes nothing. Siteminder seems to strip the CORS headers :/
Another thing I have noticed is that if i craft the failing GET request as a javascript location.href=url + "?" + queryStringData redirect everything works. Current jquery is all but depreciating setting async to false so crafting a non-async version is more than I want to tackle at the moment.
The local siteminder folks will file a ticket soon I think.
EDIT 2
I have ended up with a hacky "fix". I can not use standard GET, POST, PUT, etc methods to interact with the MVC methods because Siteminder is in the way. I have added CORS headers and have tried JSONP, none of that works in this case.
I have to use "redirects" instead. Setting location.href = "/usr?thing=foo&bar=baz" in the javascript functions then redirecting to the url as a result of the MVC methods.
This might be a Siteminder config issue. The local Siteminder mavens have submitted a ticket.
Your question still isn't clear what the problem is with each of the bullets you listed. Is the GET behavior what you expect? A 302 is just a redirect, is it the redirect you expect?
For "POST", you are seeing the "post preservation" behavior. Its what SiteMinder does so that if your session has timed out in the middle of filling out a form, you don't lose your work. Post preservation is a configuration parameter in the "Agent Configuration Object" in SiteMinder. It sounds like your SM admins have configured the ACO differently for the IIS server than they did the Linux server.
PUT - nothing happens? You don't get any response at all, the connection just hangs?
Your last bullet, with the redirect loop, this looping typically indicates that your user is logged in (authenticated) but not authorized, which is a SiteMinder policy configuration issue (again it sounds like different policies are being applied to your IIS server than the Linux)
HTH!
-Richard
I am trying to wade my way through learning IdentityServer so that I can implement single sign-on at my workplace. I have a POC service running locally and when I request the configuration, this is the configuration that displays:
{"issuer":"https://localhost:44345/core","jwks_uri":"https://localhost:44345/core/.well-known/jwks","authorization_endpoint":"https://localhost:44345/core/connect/authorize","token_endpoint":"https://localhost:44345/core/connect/token","userinfo_endpoint":"https://localhost:44345/core/connect/userinfo","end_session_endpoint":"https://localhost:44345/core/connect/endsession","check_session_iframe":"https://localhost:44345/core/connect/checksession","revocation_endpoint":"https://localhost:44345/core/connect/revocation","introspection_endpoint":"https://localhost:44345/core/connect/introspect","frontchannel_logout_supported":true,"frontchannel_logout_session_supported":true,"scopes_supported":["openid","profile","email","roles","offline_access"],"claims_supported":["sub","name","family_name","given_name","middle_name","nickname","preferred_username","profile","picture","website","gender","birthdate","zoneinfo","locale","updated_at","email","email_verified","role"],"response_types_supported":["code","token","id_token","id_token token","code id_token","code token","code id_token token"],"response_modes_supported":["form_post","query","fragment"],"grant_types_supported":["authorization_code","client_credentials","password","refresh_token","implicit"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"],"code_challenge_methods_supported":["plain","S256"],"token_endpoint_auth_methods_supported":["client_secret_post","client_secret_basic"]}
As part of this, you can see:
"response_types_supported":["code","token","id_token","id_token token","code id_token","code token","code id_token token"]
However, when I send a request to the service, with responseType=id_token in the url, I get the error message:
The authorization server does not support the requested response type.
I have tried other responseType values but still get this error message.
I am basically a beginner at web security and IdentityServer, so I am sure I am missing something very basic.
This is pretty stupid. All of the examples online I have looked at for IdentityServer show the parameter as responseTypes (camel case). I think these examples must have all been done against an older version of the platform.
The correct parameter name to send is response_types.
The list of possible parameters that you can send to the authorization endpoint are listed on the following websites :
OpenId RFC : http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
Identity server doc : https://identityserver.github.io/Documentation/docsv2/endpoints/authorization.html
The correct parameter is "response_type" and not "response_types" :)