I have a WebAPI, which is a part of a bigger WebForms app, deployed on IIS 10 under the https://domain/SimpleApp.
I have noticed that when calling an API endpoint using https://domain/simpleapp/api/endpoint I'm getting redirected (status code 302) to https://domain/SimpleApp/api/endpoint.
I didn't set any url-rewrite rules.
It is causing some errors when consuming the API on iOS app - some endpoints are secured, and when redirecting, the "Authorization" header is dropped (default behavior on Apple platform). For the record: the redirect occurs for both, secured and non-secured endpoints.
Is it some default IIS configuration? Can it be changed, so it will not redirect the request (or is it easier to handle this issue on the iOS app)?
Ok, I've found what was the issue. It is nicely described in this post: Beware WIF Session Authentication Module (SAM) redirects and WebAPI services in the same application
Related
Say a SPA hosted in spa.com is loaded by user in user.com and uses oauth2 server oauth2.com for authentication through auth code flow (optional with PKCE). after user authenticated, oauth2.com would send the auth code back to the web browser and instructs it to redirect to the "redirect URI" registered with the app. now since SPA runs entirely inside the web browser, which can be anywhere, what the redirect URI should the SPA sent to oauth2.com to start with?
http://localhost : suppose to be just for local testing
its own address (user.com) : will not work since it is not registered
spa.com : SPA runs entirely in browser, not connected to spa.com
i know #1 and #3 do work but can't figure out why (#3). please advise what is wrong or missing with my understanding. thanks in advance!
The redirect URI for an SPA is usually the public URL of the app itself, so in your case this will be a value similar to one of these. On a developer PC this might be a localhost URL but I would think of it as a deployed URL and try to use proper domain names:
https://myspa.com
https://myspa.com/myapp
The technique for an SPA is then to see if you are receiving a login response as part of the main page load. See the call to handleLoginResponse in this source file of mine.
[SOLVED READ COMMENTS ]
I got a problem with the asp.net core hosted Blazor app.
locally it works like charm, when it is deployed there is a problem related to the cookies, that I don't know how to fix, I did my best, now seeking help :)
The problem is: once the user comes to the login page he gets this message in the console:
Here I found those cookies in response
There is no way to fix this issue in this scenario, I have tried everything, only one thing will work that is SSL certificate.
Chrome version 80 or higher will block all third-party cookies by default. If you use the api using HTTPS, switch the protocol to the HTTPS and check whether the Set-Cookie in the response header contains SameSite=None and Secure.
If it doesn't use HTTPS, Chrome 80 will intercept the login function under the http protocol, causing the entire local deployment service to be unavailable. For this situation, open chrome://flags/#same-site-by-default-cookies and chrome://flags/#cookies-without-same-site-must-be-secure in chrome, set it to be Disabled.
I am using ASP.net webforms and successfully integrated the payment gateway. The problem I'm facing is that while I'm posting data to the payment gateway it process the payment and send backs the response to our web application and user gets logged out i.e. because user session getting cleared and sets back to null .I thought this occurs because of HTTP to HTTPS connection as every gateway uses https as a security. and after getting redirected to https it removes all the cookies and session data.
Later I have run the solution by enabling SSL in IIS express to make sure that the redirection happens from https to https, but still the problem persists.
Please help me fix this issue.
I am using ASP .NET MVC 3 to develop a site running on IIS express server. The site has to run on https protocol.
I would like to add Twitter OAuth support to the site. Twitter requires a callback url and it should not be https://localhost:44300/. Normally, for http, I know the solution is to use http://127.0.0.1 instead. However, I have tried https://127.0.0.1:44300, it did not work for me and I got a HTTP 503 error.
Is there something I can do to get the callback working with https?
Follow these steps:
1- For IIS :
1-1 make sure that application pool is not paused or disabled
check here Solve HTTP Error 503
1-2 Make sure that SSL is enabled for IIS enabling SSL for IIS
2- Make sure that port 44300 is not used with anyother application, to check that run command:
"Netstat -a"
3- review Twitter Errors code
if everything is Okay on your machine,you might need to check twitter API errors code
For example error 503 means :
The Twitter servers are up, but overloaded with requests. Try again later.
I am building an ios app that communicates with the server for getting the data.
If its just a normal app, I can send csrf token via forms (since all from same domain). But, for ios apps, I dont think I can set csrf token .
So, when making requests from ios apps, to the server, I am getting error regarding csrf. So, whats the solution for this? Disabling this csrf feature or some other better way ? This is my first ios app, so please tell me a better way so i will follow that.
For those URLs ("API end points") that your iOS app is accessing, you will need to specify #csrf_exempt on the corresponding view functions to disable csrf protection.
More details here - https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#django.views.decorators.csrf.csrf_exempt
And protect those urls via other authentication methods, such as session authentication.
For your authentication purposes, you can easily take reference to what django rest framework and django tastypie has done. Both use SessionAuthentication classes to handle authentication and protect the exposed urls (API endpoints) that your iOS app can connect to.
References:-
http://django-rest-framework.org/api-guide/authentication.html
https://django-tastypie.readthedocs.org/en/latest/authentication_authorization.html
Django tastypie also has an authorization class, which is not to be confused with authentication. It also has an APIKey authorization class which becomes useful when you do want to expose your django URLs to other 3rd party developers who may want to build an app of their own to talk to your django URLs to access data (think "facebook APIs"). Each 3rd party developer can in essence be provided a unique API and because you have the APIKeyAuthorization class and a unique API Key provided to each 3rd party app, you can be sure that only "authorized" apps can consume your django URLs. This is the essence of how various big platforms like "Google+" or "Facebook" etc work.
Details of how django's csrf works
https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#how-it-works
The CSRF protection is based on the following things:
A CSRF cookie that is set to a random value (a session independent
nonce, as it is called), which other sites will not have access to.
This cookie is set by CsrfViewMiddleware. It is meant to be permanent,
but since there is no way to set a cookie that never expires, it is
sent with every response that has called
django.middleware.csrf.get_token() (the function used internally to
retrieve the CSRF token).
A hidden form field with the name ‘csrfmiddlewaretoken’ present in all
outgoing POST forms. The value of this field is the value of the CSRF
cookie.
This part is done by the template tag.
For all incoming requests that are not using HTTP GET, HEAD, OPTIONS
or TRACE, a CSRF cookie must be present, and the ‘csrfmiddlewaretoken’
field must be present and correct. If it isn’t, the user will get a
403 error.
This check is done by CsrfViewMiddleware.
In addition, for HTTPS requests, strict referer checking is done by
CsrfViewMiddleware. This is necessary to address a Man-In-The-Middle
attack that is possible under HTTPS when using a session independent
nonce, due to the fact that HTTP ‘Set-Cookie’ headers are
(unfortunately) accepted by clients that are talking to a site under
HTTPS. (Referer checking is not done for HTTP requests because the
presence of the Referer header is not reliable enough under HTTP.)
This ensures that only forms that have originated from your Web site
can be used to POST data back.