I have web application that has Windows authentication running successfully until recently. I didn't do any changes to IIS configuration or code modification or user permissions change.
I can log in to the application, but when javascript does redirect it returns to the same page. I checked with fiddler headers. Once I initially logged-in the header has WWW-Authenticate parameter. When the redirection done through JavaScript code either AJAX or setting windows.lovation.href='MyPage' it does not pass WWW-Authenticate header value.
So, once I go directly to any page under this application it loads fine and I see WWW-Authenticate parameter, but with JavaScript the WWW-Authenticate parameter missing. Once again no change was done to server.
I assume it may relate to windows auto updates. But it is just wild guess.
Related
I have application written in asp.net MVC (NetFramework 4.7.2).
When I enter my credential and click Login button
POST to login page return 302 (with auth cookie)
REDIRECT to action returning dashboard (with auth cookie)
Everything works over HTTP, I can use my application.
But over HTTPS after dashboard is loaded auth cookie dissapears (there is no code on JS, maybe browser do it). Cookie has enabled flags HttpOnly and Secure. I use the newest Chrome to browser my app.
It's probably related with console error
Clear-Site-Data" header on '': Unrecognized type "*"
I don't why it is added, I never have such header in code. Is it possible to browser do it?
If the browser drops the cookie it will usually write a message to the dev console about why it is dropping it. Most browsers are very specific about the reason for dropping cookies.
In your case, there seems like the response contains this header: Clear-Site-Data. It's a standard header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data The backend must be returning this header for some reason. Then the browser correctly drops the cookie as instructed.
It's interesting though, why the browser complains about the asterisk value. According to the docs this is one of allowed values for this header.
I load user profile informations from instagram by the basic api in a local test app.
So this actually works like written in the documentations.
I used Postman to get along the authentication and token stuff.
The order to access the graph api, to query media fields would be like:
Get access code (from authentication window redirect url)
Get access token (from acces_token endpoint)
Get media data (from graph api by access_token)
I´m using UI5 js framework with UI5 Tooling.
I get a response with data in step 3 from ajax call, but first i have to execute step 1 and step 2 manually.
But i want to do all this authentication-mechanism directly in my app. Including opening this authentication window and acessing the code from the redirect url.
When i do an ajax call in step 1, i get an CORS error of course, because step 1 doesnt respond with the corresponding CORS header (like step 3 does).
Well, anyways i most likely could handle this by a proxy, but whats about the production environment? I dont get how this approach should ever work in a real app. Even when the CORS problems are handled by aproxy in dev environment, it should be still there when a real user uses the app.
So the question is: How can i access or implement this authentication window (on a diffrent origin) in my app? I have seen other apps doing this permission window, but i have no clue how to implement it in a web app.
By clicking "Allow" you get redirected to he redirect_url with the access code
How can i get the access code directly in my app, avoiding CORS in production
I don't have a definite answer, but regarding your CORS issue: It seems like instagram added a CORS policy somewhere last year (see this other question on SO). This means that you would indeed have to build a proxy.
Basically you need something that accepts all the endpoints that the original API accepts, forwards them to instagram, reads the response, and returns the response to the client (aka browser). But your proxy will then not add the CORS headers. Or even better, you add your own CORS headers (assuming your proxy and your app will run on the same server) and no one else will be able to use your proxy from their web app.
Unfortunately I don't know about this authentication window. Maybe this is just a fancy way to hide that they are running a proxy behind the scenes as well? You should be able to see in the network tab where the insta data is coming from after you login. I would guess not directly from their graph API.
How can I detect if user escapes out of Authentication Required dialog in browser?
Is there JS for this cancel / escape key event ?
I don't need to know which user, just to redirect them to a unauthorized page.
I honestly have no experience with this specific popup, but it is part of the Basic Authentication protocol inherent to HTTP. What happens is when the browser requests a protected resource from a web server, the server responds with an unauthorized status code (401) and a header called WWW-Authenticate, and the browser shows this popup on its own. This popup is not related to JavaScript in any way, and as such, we can't detect it using JS.
We can, however, check for the presence of the Authorization header in the client's response on the server, and if the header exists, and is correct, then serve the protected route; otherwise, serve a different route. I don't know if it's possible to check for the header on the page, since it's not loaded yet, but you can definitely have your server make that decision before serving the response.
I have an MVC application that is authenticated with Federation Services. All the requests are routed through a Web Application Proxy, which redirects to ADFS for authorisation if necessary, and the security tokens passed to our app.
When the session expires the WAP redirects to ADFS and an automatic reauthorisation happens. Which is fine for a normal page load.
But when a page makes an ajax call we get a 307 redirect, which our jquery ajax calls fail to handle. There is a CORS issue as the ADFS redirect is to a different domain.
I'd like to be able to intercept this call and display a message or redirect to the login page. How can I achieve this?
I have the following restrictions:
We must use WAP
I'm not able to change any configuration on WAP. Which means I can't add an Access-Control-Allow-Origin header to the redirect.
As we're using WAP my app doesn't even know of any authorisation failures and I can't send back a 401 to be handled by the client side code, which is what I'd normally do
So I think I need a JQuery/JavaScript solution to this.
Thanks
I'm hacking together a script to automate the submission of tickets to our helpdesk system. So far it's a very simple, but working system. I have a page with a form that auto-submits via JavaScript with form value based on the URL requested.
This works great when you access the page from your browser. Assuming you're already authenticated to the ticket system page, the auto-submitted form happily sends its form data and you are directed to the ticket list where you see the newly auto-submitted ticket. Unfortunately of course, the ticket system is an HTTPS secured site, so if you're not logged in you're directed to the login page and the auto-submission fails.
The idea however is to run this auto-submission on a schedule, or kick it off remotely, where the initiator won't necessarily be human and won't be following the form submission to babysit it with delicious authentication cookies.
So, being a newbie in this area, my options seem to be A) dive in and get real messy by listening for the auto-submission response, determine whether the login page is being returned and submit some credentials via JS (not a huge deal as this automation would run solely on a secured server), then resubmit the form... or B) somehow do this the proper way by authenticating beforehand. But that's where my knowledge ends.
I've read through this similar question, but am still coming up short. Is this proper automation only possible if the server in question supports some form of auth token API? Is there not a more direct way to connect and request/submit data to an HTTPS site? I've been glossing over some introductions to cURL, but have not yet dove in.
NB: I don't have direct access to the ticket database, code, nor to the web server processes/accounts running it. I probably can run processes on the same machine, which is why I'm not real concerned with the security of auto-submitting credentials, but that's probably it.
Firstly, whether your ticket system directs you to a login screen if you're not already authenticated has nothing to do with HTTPS - this will be either a username/password <form> that then sets a cookie, or it will be a WWW-Authenticate header. Each of these can be used whether you are using HTTPS or plain HTTP.
Whichever method it uses, if you're planning on doing this in a web browser, chances are you won't be able to because CORS (cross-origin resource sharing) will probably not have been set up to allow it.
If however you're doing this from a script such as Node.js, Python, PHP or anything else that can make arbitrary HTTP(S) requests, you might want to look at a flow like this:
Request the index page of the ticket system
Detect whether it gave you a login screen
If so, fetch any necessary data from the login screen (e.g. a nonce) and make a POST request as if you filled in the username/password yourself
Check that authentication was successful (based on the POST response)
Keep the cookie returned by your POST request and use it to submit the ticket.
For the simpler case where the system uses a WWW-Authenticate header it would be like this:
Request the index page of the ticket system
Detect the WWW-Authenticate header in the HTTP 401 response received
Send an Authorization header with an appropriate value
Check that authentication was successful (based on getting an HTTP 200 instead of a HTTP 401)
Send the same Authorization header again while submitting the ticket.
Using WWW-Authenticate is described at Wikipedia for basic and digest authentication.