This is killing me.
So I have a backbone site where when the user logs in, a GET request is made to the server and an access token is returned. Everything is working in FF, Chrome, IE10.
When I look at code inspector in IE9, the network tab does not list the get request to my API at all (not even as pending or failed). When I console log "error.status or error.statusText", it returns with:
0 Error: Access is denied.
My API has "Access-Control-Allow-Origin: *" enabled. I have also added "jQuery.support.cors = true;" to my initialize function in router.js. Now I am just out of ideas! I would really prefer not to setup a proxy.
if you are using backbone than probably you are using jQuery too, so i think you should check this post : Simple jQuery post not working on Internet Explorer 9 (access denied)
Related
I'm trying to use ITfoxtec.Identity.Saml2.MvcCore on a .NET Core 3.1 web application using an in-house IdP.
It works great on our test server (Windows Server 2012, hosted in the IIS) but I can't get it to work on any other server.
This is what happens:
The initial call to the website is correctly identified as a non authenticated call and the user is being sent to the IdP where the user logs in as usual. The SAML-token is then posted back to the web applications assertion consumer service where everything seems like it does what its supposed to, saml2AuthnResponse.Status has statuscode Saml2StatusCodes.Success and the logfile says "AuthenticationScheme: saml2 signed in". Then it reads the ReturnUrl-parameter and log something like "Executing RedirectResult" but then it just stops. Nothing in the logfile, nothing in the IIS-logs. The user is met by the message
This site can’t be reached
...
ERR_HTTP2_PROTOCOL_ERROR
In short, every controller that has the [Authorize]-attribute gives the ERR_HTTP2_PROTOCOL_ERROR-error. When I remove all [Authorize]-attributes the application works great, although without authentication.
I've also tried the example TestWebAppCore-application from ITfoxtec.Identity.Saml2's github-page and it gives the same error. It works on our 2012 test-server but nowhere else.
Any ideas that I can try?
I think you need to trace the calls to see the actual http request and responses send between the browser and server. I usually use Fiddler for tracing the requests/response. Remember to enable Fiddler for https tracing.
My first thought is that the problem can have something to do with cookies. But it is only a guess...
You might be on to something, we disabled http/2 on the server and was greeted instead by this message:
Bad Request - Request Too Long
HTTP Error 400. The size of the request headers is too long.
It uses 5 cookie-chunks for the SAML-data for a total of 19941 bytes which is a bit to much. I've tried to make the application save the sessiondata in classic session objects instead but I cant seem to get it to work.
This is what I added to StartUp.cs:
In ConfigureService:
services.AddMvc()
.AddSessionStateTempDataProvider();
services.AddSession(options =>
options.Cookie.IsEssential = true
);
services.Configure<CookiePolicyOptions>(options =>
{
options.CheckConsentNeeded = context => false;
options.MinimumSameSitePolicy = SameSiteMode.None;
});
In Configure:
app.UseSession();
But it still fills up the header with cookies. What am I doing wrong? Is there a another way to make the session cookies smaller?
When I make an $http.post request and set the "withCredentials" property to true.
My request works fine in Chrome and Fiefox. However, I'm getting the error below in IE:
XMLHttpRequest: Network Error 0x80070005, Access is denied.
I noticed that if I enable the "Access data resources across domains" setting in IE, The error gets resolved. However I need to find an alternative solution because I can't ask the users to enable that setting obviously.
I noticed that a $http.get request to the same domain is working in IE with no issue, the issue is only with the $http.post request, the Options request is getting a 500 internal server and I see the request and response headers below:
Note:
I do have the necessary custom headers, and I can see them in Chrome when the OPTIONS request succeeds. The headers that I see in Chrome are listed below:
Could you please let me know if I'm missing something that would make the request work in IE without having to enable Access data sources across domains?
Internet Explorer 9 doesn't support cookies in CORS requests. The withCredentials property of the $http arguments attempts to send cookies. I don't think there's any way to fix it with headers. IE10+ should work by default, just be sure that you are not in compatibility mode. CORS isn't fully implemented in IE10 either, but the type of request you are trying to do should work.
You didn't mention what the nature of your web app is, but it impacts the type of workaround you will need for IE9. If possible, see if you can refactor your code to use a GET request instead (again, I don't know what you are trying to do via AJAX so this may be impossible).
You may be able to use Modernizr or something similar to detect if the browser supports CORS. If it is not supported, send the request without AJAX and have a page refresh.
Another alternative if you really want to use AJAX is to set up a proxy on your web server, i.e. the server on the same domain. Instead of making the cross-origin request directly, you make the AJAX request to your same-origin server, which then makes the request to the cross-origin server for you. The server won't have CORS issues. This solution assumes, of course, that you have some server-side scripting going on such as PHP, Node or Java.
I have custom api written in WebApi2 that serves some data in json. I'm trying to access that particular API from Ionic on iOS and Android using Angular's $http. On Android everything is ok and I'm receiving correct result. But on iOS strange thing happens, as $http even don't send request and throws error immidiately, returning http status code 0. This problem exists only on iOS emulator and iPhone. Moreover, this behavior is not observable when requesting any other site or fake test api.
What I already tried:
Add "Access-Control-Allow-Origin: *" header.
Add proxy to ionic.project, but this fixed the problem only when running Ionic Serve
Add in config.xml
configure angular to use cross-domain by setting this:
$httpProvider.defaults.useXDomain = true;
delete $httpProvider.defaults.headers.common['X-Requested-With'];
Any clues? Maybe this is server-side problem?
Does this also happen on an iOS version lower than 9.0? Because there has been some problems with $http since iOS 9.0. If it doesn't, it would check out this article.
Looking for solutions
When I started searching for this error I found this forum thread. It
said that the contributors had got this error too and that the error
is triggered when a network request is made using the $http service. I
used $http in my app too, but I didn’t make any request through it
when the app was starting. Also, in the forum thread it said that the
problem is triggered by adding custom headers to a network request. To
solve the problem, headers shouldn’t have a leading space in the
value. I had custom headers but I didn't have any spaces before the
value. So I decided, (wrongly as it turned out), that this article
couldn't help me.
Here’s what I tried next:
I read all the advice from Ionic's blog article again and tried to
apply it to my project - it didn’t help. I decided that as I was
getting the error in vendor files, I should try updating Ionic
Framework, Ionic CLI and all third party libraries (Angular,
Restangular, ngStorage, ...) - it took some time, but when I ran the
app again I got the same error. I created a new "clear" ionic app and
it worked properly - so I was sure that the problem was somewhere in
my code. I started debugging the app and digging around in my code in
"the old school way" - trying to cut out blocks of code and see if the
app would then work (because I got the error before it was possible to
use any Safari dev tools for debugging). In this way I found out which
line in my code was triggering this error. It was this line:
$http.defaults.headers.common.Authorization = 'Basic ' + $localStorage.user.authToken;
I use my own service in dependency
injection which executes a line of code (see above) when the service
is initialized. This is why the $http service was also causing the
error I was encountering. I removed this line from my code and
replaced it with authorization token headers in the configuration of
each request, like this:
$http.post(appConfig.apiUrl + 'profile', data, { headers: {'Authorization': $localStorage.user.authToken} })
After that my app started to load (Hurrah) which let me see some other
problems (Booo).
When I test the setup on my laptop Chrome browser everything works just fine using both sameWindow and newWindow: I am able to login though for example Facebook and the user is authorized and can use my app.
However, when I try to deploy the app to android and use the inAppBrowser things break. When selecting the 'login through FB' button in my app I can see the inAppBrowser frame come up with the Facebook mobile site asking to login. When I inspect that specific window through Chrome inspect, I can see that the callback from FB coming in to omniauth on my server including state and code in the querystring:
https://<app>.herokuapp.com/omniauth/facebook/callback?code=<code>&state=<state>
This request receives a 302 redirect to the following URL:
https://<app>.herokuapp.com/api/v1/auth/facebook/callback
This follow-up request receives a 200 response. So far it all seems fine and the inAppBrowser window closes, we get back to my mobile app and I see the ng-token-auth "auth:login-success" event passing by.
However, any subsequent API requests to my server receive a 401 Not Authorized response. When I look at the request headers of those API requests I don't see any of the headers that Chrome on my laptop is sending to the server such as: access-token, client, expiry, token-type and uid.
I would be very grateful for any advice on where to look or what I am missing here.
Thanks!
Turns out that when working with ionic and I assume it is the same with cordova, storing the tokens according to default behavior in the cookie does not work. However, once you configure it to work with localStorage it works great!
For more info see this issue I opened at the GitHub project.
I have the problem that even though I set the $http.defaults.headers.common.Authorization to null I am still capable of accessing the [Authorize] part of my Web API 2.0 application.
This problem doesn't arise when I start the application from scratch and try to retrieve the data via an initial GET request. This is when I get an error from the $http callback function.
Any guesses why this is happening? I am quite confident that the bearer token is stored somewhere in the browser and doesn't get deleted properly ...
Chrome (With bearer token):
Chrome (Without bearer token):
Internet Explorer (no bearer Token attribute):
First of all, the authentication property in IE is completely missing. Second, in Chrome everything works perfectly. In IE I have the issue that I can't erase the token for the logout request. The login part with the summary of the regions [Authorize] part works perfectly.
Make sure you haven't also configured jQuery to do this, via something like $.ajaxSetup
Try to check the request that have been set, if any Authentification header is there. Also try to verify that you are using the [Authorize] attribute from System.Web.Http and not System.Web.Mvc