Asp.net and android webview problem - asp.net

My IIS server requires authentication to access the localserver
this is causing android WebView component to get 403 error once directed the the url
if I uncheck Basic Authentication under Directory found in
Computer Management -> Web Sites -> Properties
I would receive 403 error(Access Denied) this time including my browser
once I restart my computer
How do I disable authentication without losing access to it?
if this is not possible
Is there a way to allow android WebView enter the username and password
automatically to prevent 403 error?

You need to handle Basic Auth in WebView: How to handle Basic Authentication in WebView

Related

why IIS prompts for credentials after backend returns http 401 code (unauthorized)

I have IIS 8.5.9600.16384 running on Windows Server 2012R2 and a website configured as application with separate application pool.
In IIS Authentication only "Anonymous Authentication" is enabled. To perform authentication, my site uses it's own login prompt and calls a .net core backend with basic schema, something like
POST /mycorebackend/login
with http header
Authorization: Portal base64encoded_username_and_password_here
Everything works just fine if authentication is successful and backend responds with HTTP OK.
But if backend returns 401 Unauthorized I've got pop-up from IIS asking me to provide credentials, like I'm trying to access a folder with some content, but I'm not.
I just need to get my 401 error and continue my js execution without any prompts.
Can anyone help or at least give a me hint where to search for?
I think this may be related to IIS-kestrel integration or so... For some reason IIS tries other schemes or so...
Thank you
I think you are looking for these settings. that should resolve it

IIS Forms Authentication throws a 401 Error

We are currently setting up forms authentication for our web app.
The plan is for users to be redirected to a login page on our main system when they want to access files.
IIS Settings
Setting the IIS "Authentication" to anonymous gives access to the files.
BUT when we change the authentication to "Forms" and disable everything else we are met with a constant 401 error when trying to access the file.
401 Error
There is no redirect. It just throws this error.
The Web config has been changes to allow "?" (anonymous) and allow="*".
This does not change the 401 error.
When anonymous access is enabled (alongside forms auth) there is no redirect. The users have direct access to the files. (As if forms authentication is not even enabled?
Web Config
Please note that I also had to add machine keys to my web.config and also had to add the domain name in the authentication tags (also in the web config). After also adding a cookie.domain in my C# side the authorisation is finally working between domains.
--This has to be done when working with 2 subdomains. Eg: 1.website.com and 2.website.com.

Chrome ignores HTTP WWW-Authenticate realm

Our web application has user/password authentication. It runs on a web server which is secured itself with HTTP Basic Auth. This is just a temporary solution / workaround. The web application's authentication will be sufficient in future, but at the moment the web server Basic Auth prevents accessing the web application at all.
The web application returns status code 401 when not authenticated on application level. The WWW-Authenticate header defines a different realm, so the browser won't get confused between web server and web application authentication: If we didn't define a different realm the browser would throw away the web server credentials as soon as the application's 401 arrives.
So far so good. However our application has its own authentication dialog. For XHR requests we want to handle the 401 status on our own and need to prevent the browser's internal basic auth window. There is a simple trick for this: Just adjust authentication header (WWW-Authenticate) to use a custom auth method:
WWW-Authenticate: CustomBasic realm="myapp"
Whereby the web server returns:
WWW-Authenticate: Basic realm="webserver"
This works with Firefox but not with Chrome. Chrome ignores the realm when using CustomBasic and discards the credentials (user / password) for realm "webserver" as if we didn't define the realm "myapp" at all.
Do you know why? Do you know a solution with following requirements:
Keep 401 status for both realms
Do not show browser's basic auth window on application level (especially for XHR requests)
Yes I know we can simply workaround this by using different HTTP status codes on application level and handle them respecitvely. But if possible I want to keep the correct status codes 401. This could also be a valid use case, e.g. if you have two web applications accessible with two different URL paths on the same host.

Access windows Authenticated Web API through Angular 2 without login prompt

I have already developed front-end application in Angular2 and back-end in ASP.net web APIs. I had used Windows authentication as enabled because I want to detect requesting user. Both applications are hosted in IIS server(Windows Server 2012).
When I load angular app it load login prompt and when give correct user credentials data loading happen correctly.
But I want to know a way to load them without login prompt, authenticate automatically.
This is the way I detect request user in web APIs.
string user = HttpContext.Current.Request.ServerVariables["LOGON_USER"]; //Get the current user...
userID = user.Split('\\')[1];
This is a sample TS script send request to Windows Authenticated Web APIs from Angular Services.
getPersonalInfo(): Observable<IPersonalInfo> {
return this._http.get(localStorage.getItem('WebApiURL') +"api/PersonalInfo/" , { withCredentials: true })
.map((response: Response) => <IPersonalInfo>response.json())
.catch(this.handleError);
}
When restart the browser this login ask every time.
I want to access them with out this login...
Actually, this login prompt occurs because there is communication between two technologies (ASP.net & Angular 2) by passing windows windows credentials. So it need shake-hand authentication when call windows authenticated API.
I was lucky to find a solution by changing privacy settings through browser. So I got ability to call API's without login prompt.
Here is the way to do that.
Settings -> Open Proxy settings -> Privacy ->Sites
In here you can add domain where your back-end APIs are already hosted as in example.
After that it take as trusted domain and further more there is no any login prompt accruing.
I have spent a lot of time on this, and I'm not sure it can be done. If you enable Anon Access then the [Authorisation] on the controllers works fine. But you can't detect the username.
If you disable the Anon Access then you can obtain the username NETWORK//USERNAME but if you access a method with the [Authorize] attribute then you get the popup dialog you have got.
I really don't want to go back to a username/password solution but it is looking like I am going to have to.

Cannot authorize with different server name

I have a web service running in IIS 6.0 on Windows 2003. It's authentication mode is Integrated Windows security (anonymous disabled), and authorization is done with Authorization Manager and an XML authorization store. My test user is a domain user (admin, actually) with membership in an authorized role.
I am testing this (for now) on the web server (localhost), and using (for now) Internet Explorer to access the web service (.asmx).
I can successfully open the web service (wsdl) page through localhost, like this:
http://localhost:8080/MyService/MyService.asmx
Using this url, integrated windows authentication succeeds (silently), and I am sucessfully authorized by AzMan to access the service. The same goes for the server name:
http://myserver:8080/MyService/MyService.asmx
Now I need to use the external host name (www.mysite.no) to access the service (this in order to get ssl to work with a certificate issued to that sitename). To do this, I add the host name to my HOSTS file, like this:
127.0.0.1 www.mysite.no
...then type this into IE:
http://www.mysite.no:8080/MyService/MyService.asmx
What happens then is that authorization fails. I get the IE/Windows login box and enter my correct credentials three times. Then I get a 401.1:
HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials.
Internet Information Services (IIS)
How is authorization through AzMan influenced by the host name?
Edit: I have reason to believe AzMan has nothing to do with it - it seems to be the authentication that fails.
I have reproduced the problem on another server. The essence seems to be that accessing localhost via an entry in the local host file somehow messes up the integrated windows authentication between the browser and IIS.
I have worked around the problem, now my curiosity is all that's left...
Enable audit login failure auditing & check the security event log on the host.
1) On the webserver, go to Control Panel, Administrative Tools, Local Security Policy.
2) Go to local policies, audit policy. Add failure for 'audit logon events'.
3) Close the MMC. Open a command prompt and type gpupdate.
4) browse to http://www.mysite.no. You will get the error again.
5) Launch event viewer (control panel, admin tools, event viewer). Navigate to the security event log and look for the login failure(s).They shoudl tell you something descriptive, like 'the user has not been granted the specified logon type'. Unfortunately the login type itself is not descriptive; logon type 2 is interactive (locally), 3 is 'access this computer over the network', 5 is 'logon as a service' (NT service, not WCF service). The rights required can be granted in the local security policy.
Also, check to see if you have a proxy enabled in IE. If your traffic is being routed to the proxy, it is possible that the proxy does not support NTLM. Add the host as a proxy exception while you test using IE.
My first guess is that it's not the host name.
The first thing to do is narrow down the problem as there are a couple things that could be going wrong.
First set the IIS site to anonymous access, and make sure you can pull up the web service. That will verify that you're accessing the right IIS web site and it's truly narrowed down to an authorization problem.
Also, check the Application Pool credentials, and the security settings on the file folder containing the web service as these could be contributors.

Resources