User open the index page presented with basic browser authentication, but he doesn't respond and provides username/password.
In this scenario, I want to kill that http request, is there any way of doing it. I remember we can set a timeout cookie but not sure.
Would window.stop(); work? There's a way to cancel an ajax request using <object>.abort(); but I don't think that will help you in your situation.
Related
I have a situation, when I should to send a POST request to authenticate user, if it's succeed then server set a cookie and then we can get a protected page:
First request by Postman:
Second request (after first):
I need to implement it on web page. As I understand now, it's possible only via frames. How to do it? First request should be sent automatically after opening a page, so, user should open the page and see a protected page.
Cookie Authentication is you are trying to achieve?, here is are some links which will help to you with that.
https://dzone.com/articles/cookie-authentication-with-aspnet-core-20
I have a RESTful backend which per definition is stateless. However, I do require authentication. For this, I plan to use Basic HTTP authentication. Since that requires the username and password to be sent with every request, I want to store them clientside.
I was thinking of using the HTML5 session storage for this. The overal browser support is good enough for my application but there is one issue.
I need to catch the event when the session storage is cleared, for instance by closing the tab or clicking the logout button. Before actually clearing the session storage, I need to send the credentials to the RESTful server one last time so it can perform a clean-up operation for that user.
The issue is not so much with the logout button but more so with the tab or browser being closed...
How do I catch this event (with some Listener perhaps?), and delay it from happening until I've made a final REST call?
As far as browser and tab concern you can try following link.
https://developer.mozilla.org/en-US/docs/DOM/window.onbeforeunload
Don't know why people do not practice AJAX implementation for authentication systems. Is it insecure? If yes how? I have developed an authentication system that submit user information through an iframe, but the problem is it opens a new window in IE6.
Don't know why people do not practice AJAX implementation for authentication systems.
Usually because the differences between "logged in" and "not logged in" are quite significant, so the cost of reloading the entire page is relatively insignificant.
Is it insecure?
Not intrinsically. Security comes from SSL, not from forms or JavaScript.
There is no difference, they are both sent exactly the same way.
It's all just http.
It makes a difference if you are sending authentication over ssl, how cookies or authentication headers are encrypted and so on.
What doesn't makes a difference is if it's an AJAX request or an IFrame or a Form post and so on.
I have a form which is posted to an MVC3 controller that then has to be POSTED to an external URL. The browser need to go to the URL permanently so I thought a permanent redirect would be perfect.
However, how do I send the form POST data with the redirect?
I don't really want to send another page down to the browser to do it.
Thanks
A redirect will always to be a GET, not a POST.
If the 2nd POST doesn't need to come from the client, you can make the POST using HttpWebRequest from the server. Beware the secondary POST may hold up the return of the client request if the external server is down or running slowly.
A permanent redirect is wholly inappropriate here. First, it will not cause form values to be resubmitted. Second, the semantics are all wrong - you would be telling the browser "do not request this url again. instead, go here". However, you do want future submissions to go to your same url.
Gaz's idea could work. It involves your server, only.
Alternatively, send a form with the same submitted values and the external URL, and use client-side code to automatically submit it.
If your API and Website making ajax calls to that API are on the same server (even domain), how would you secure that API?
I only want requests from the same server to be allowed! No remote requests from any other domain, I already have SSL installed does this mean I am safe?
I think you have some confusion that I want to help you clear up.
By the very fact that you are talking about "making Ajax calls" you are talking about your application making remote requests to your server. Even if your website is served from the same domain you are making a remote request.
I only want requests from the same server to be allowed!
Therein lies the problem. You are not talking about making a request from server-to-server. You are talking about making a request from client-to-server (Ajax), so you cannot use IP restrictions (unless you know the IP address of every client that will access your site).
Restricting Ajax requests does not need to be any different than restricting other requests. How do you keep unauthorized users from accessing "normal" web pages? Typically you would have the user authenticate, create a user session on the server, pass a session cookie back tot he client that is then submitted on every request, right? All that stuff works for Ajax requests too.
If your API is exposed on the internet there is nothing you can do to stop others from trying to make requests against it (again, unless you know all of the IPs of allowed clients). So you have to have server-side control in place to authorize remote calls from your allowed clients.
Oh, and having TLS in place is a step in the right direction. I am always amazed by the number of developers that think they can do without TLS. But TLS alone is not enough.
Look at request_referer in your HTTP headers. That tell you where the request came from.
It depends what you want to secure it from.
Third parties getting their visitors to request data from your API using the credentials those visitors have on your site
Browsers will protect you automatically unless you take steps to disable that protection.
Third parties getting their visitors to request changes to your site using your API and the visitors' credentials
Nothing Ajax specific about this. Implement the usual defences against CSRF.
Third parties requesting data using their own client
Again, nothing Ajax specific about this. You can't prevent the requests being made. You need authentication/authorisation (e.g. password protection).
I already have SSL installed does this mean I am safe
No. That protects data from being intercepted enroute. It doesn't prevent other people requesting the data, or accessing it from the end points.
you can check ip address, if You want accept request only from same server, place .htaccess in api directory or in virtualhost configuration directive, to allow only 127.0.0.1 or localhost. Configuration is based on what webserver You have.