I'm trying to remove the user's authentication cookie by using $cookieStore.remove('.ASPXAUTH'), but if I refresh the page afterwards, the cookie still exists and the page is still available instead of the user being redirected to the login page as I would expect.
Why is the user still able to view the page after I delete the authentication cookie and refresh the page?
I'm afraid that there isn't much you can do to a http-only cookie with javascript. The backend has to remove it if it's http-only. you can trigger a logout by using ajax.
$http.get("/logout");
The other option is to use non http cookie so you can modify it with javascript. But that would make it vulnerable and unsafe for risk of an XSS flaw grabbing your cookie and allowing your session to be hijacked.
PS: try HEAD request method if you don't want to load the page that follows (might work like an "do-and-forget-about-it")
$http.head("/logout");
Related
I have a login button that opens a new window to a third-party login page. If i. Logged in first time, any time i refresh the page or open the website in a new tab when i click on the button it redirects me to the cached login response data, and i have to clear both my website and the login website cookies completely(website+external ones(google cookies.. etc))..
So is there is a way to force clearing all website data from javascript? Or any way to avoid this caching issue?
I have already tried to delete document.cookie but it only delete only the domain cookie not the external ones.
Generally, an app with a third party authentication flow is like from your app, you check the credentials in your cookie to see whether they are valid.
If they are not valid or do not exist, open the third party authentication dialog then login. After a successful login, mostly, the 3rd party auth should saved something in the cookie with its domain. And you also need to save something about credentials in the cookie.
If there are valid credentials in your cookie, then you are simply authorised and the credentials in the cookie should be good to use.
Back to your 2 questions, So is there is a way to force clearing all website data from javascript? Or any way to avoid this caching issue?
Why do you need to clear those data for the sake of authentication?
For the second question, I think I answered it already with the general introduction.
I´m trying to build a pure JavaScript app, This app does call to an API, and that API return a token which I will save in a cookie (any advice about it?).
I have many doubts, the most important are the following,
How should I make the redirect stuff between pages, and how I prevent that someone access to my page, I want to do something like if there is not cookie (token) and the token is invalid (I will check the token before show the page), redirect to login, if is all correct, show the home page for example
Since you have your token in a cookie you should start page load with an API call that verifies session. If API returns false simply redirect user to login page, otherwise execute rest of your javascript. I assume your sensitive data will come from subsequent API calls that should also verify the token.
You probably understand that you can't protect the static content using this method since anyone can add breakpoints on browsers and modify the JS code to their preferences (as in remove the forced redirect), so your focus should be on loading everything you want to be hidden through ajax API calls that are secured with token.
I want the user to be able to submit and render untrusted HTML within an application on say domain example1.com. In order to prevent malicious XSS from capturing the user's cookies the idea was to open the HTML in an iframe that uses a different domain, let's say example2.com. But in order to see this HTML the user has to be logged in on example1.com. How do I only render the HTML in the iframe on example2.com only if the user is logged in and authenticated on example1.com?
I was thinking maybe using a secret passed via postMessage that posts a form to render the HTML without ever setting a cookie. Anytime I wanted to update the iframe's content via JavaScript I simply recreate the iframe and then pass in the secret again and post the form again to render the untrusted HTML. Malicious JavaScript would not have access to the secret as that existed only on the previous page that posted the form. Would that be a good solution or is there something better?
Everytime that a user logged in example1.com you create a token for it.
To call your iframe content use something like example2.com/view.php?page=1&token=dsjahdjkhjh331
So the malicious script only could get the token, not the cookie. And if you create a "fingerprint" to the token, like concat the user with request address(IP) + browser agent, stealing the token is the same like stealing a random string.
I have a web application which is used by lots of non-technical users. I have found that several of these users are saving the login page of the application to their desktops (which also saves the associated CSS and JS files). Then, to start using the application, they double click on that desktop icon which shows the local copy using the file:// protocol.
This can cause problems later on, e.g. if I change the login form, or the URL it posts to, etc. Also, certain javascript utilities, e.g. PIE.htc don't work using the file:// protocol.
Obviously what they should be doing is saving a browser bookmark/favorite, I'm looking for a way of detecting and warning those users without confusing the rest. I have been using some javascript to warn these users:
if (top.location.protocol == 'file:') {
alert('This application is not designed to be accessed from a desktop copy...')
}
But this will only warn users that have saved the desktop copy since I have added this piece of javascript.
Has anyone else had this problem and come up with clever solutions that they'd like to share?
Thanks
Update:
In the end I decided to do this by setting a cookie with a nonce value upon login page request, and storing the same value as a hidden field in the form. Then, in the form submit handler, check that the two are the same and show an error message if not. One could store the nonce in a session instead of a cookie, but I don't want to create unnecessary sessions.
If the user has saved the login page locally, they will likely have different nonce values in the saved form compared to the cookie (if they have a cookie at all).
Normally one wouldn't add CSRF protection (that's sort of what this is) to a login form, but it fulfills my requirements. I read about this technique on The Register, http://www.theregister.co.uk/2009/10/02/google_web_attack_protection/, Google implemented similar protection for their login forms, to protect against forging of login requests, http://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests.
I think your best bet is going to be educating the users to use bookmarks instead of saving physical files.
Other than that, there's probably a way to create a shortcut to your URL instead, perhaps during logon?
Maybe cookies? If site is running with file:\\ there probably are not any cookies within request. (Of course, now you should add some cookie (session data) on your login page.
Also, read about CSRF http://en.wikipedia.org/wiki/Cross-site_request_forgery and preventing method.
You could probably check the http referrer on the server side and warn users not coming from your hosted login form.
Edit:
Actually, a vaguely similar question has been asked before and got a good explanation why referrer is not an ideal solution and also provides an alternative solution: How to check if a request if coming from the same server or different server?
Why, don't you, instead of the alert, put a redirect to your page?
window.location = 'http://www.yourdomain.com'
Or you can also force a reload with window.location.reload();
Instead of message you may redirect your user to the real page which has login form, or show the help box that will explain that user should save page in such way.
You could set a session variable that is set as a hidden variable in the form. If that is not there, you redirect to your login form.
I want to implement a logout function. When a user clicks Logout, I want to end their session and redirect to another page. Sadly, I am limited to only JavaScript.
EDIT:
Moving this over to Zendesk because it seems like they have a Remote Authentication API.
Thank you to all the people who answered.
Assuming your login session state is stored in a cookie that isn't httpOnly, you can simply delete the login cookie by setting its expiry date to a the past. For example, using this cookie library:
$.cookie('login_cookie_name', null);
Then you can just do a location.assign('/logged_out_page.html'); to redirect to another page.
It depends on what server technology you're using.
Let's say there's a logout.aspx page. You could just do an AJAX request to that page to zap the session, or delete a cookie that the application might be using to cache authentication, then redirect like so:
window.location = "http://www.mysite.com/logout.aspx";
UPDATE
I just found this post on SO that should help (that wasn't easy):
https://stackoverflow.com/questions/3237476/zendesk-remote-auth-using-java