I have a blog that requires users to login to view the content. But my page checks for a cookie, if cookie exists then it shows the content (to avoid users having to login repeatedly).
I want to send out an email to my subscribers with links to new posts. Is it possible for me to create a cookie when they open the email or click the link and then recognize that cookie on my website to prevent the requirement of them needing to login?
No.
Most email clients capable of rendering HTML will not, by default, load any remote content or run scripts. And using a JavaScript cookie for authentication is inherently insecure anyway.
Give the a link to click on in the email with a one-time-password and set a http-only, secure cookie from the page the URL links to.
Related
I am developing a webpage using HTML, CSS & JS. In a section with a list of links, when a user clicks on any of the items in the list I want the user to first have to sign in before they continue on the path of the item they selected and I want to do this without having to duplicate a sign-in page for each stage. I want the link to first go to the login page(login.html) then continue or go back to the path it was on
the problem now is I don't know how exactly I can achieve this without creating multiple copies of the login page
You must persist user state somewhere, either in browser (not safe at all) or on server.
In server: Save information to cookie/session
In browser: Save information to session/local storage
On every protected page visit check if user has been authorized by checking previously set flag. If it's not authorized, then redirect to login page. After successful authorization redirect back to requested protected page.
I'm currently trying to find a way to redirect the user to an external protected page, for example foo.com/dashboard. I have the user login credentials and auth cookie for the page. So my question is that how I can redirect the user to that page already logged in, so the user doesn't have to login, I do the login? I will have to add an Cookie header to the request, but it isn't possible with html.
For example, my website is bar.com and I have the users auth cookie to foo.com.
i want to be able to redirect the user to the dashboard
dashboard, but it's not possible to add a header to a html link.
I have the user login credentials and auth cookie for the page. So my question is that how I can redirect the user to that page already logged in
In general, you can't.
There is no way to set cookies for a different origin. That would be a major security problem.
It might be possible to submit the login credentials to the login mechanism on the other site, but that would depend on the site supporting a login mechanism that allowed it (e.g. a form submission) and not doing anything that would prevent it (such as CSRF defences or a CAPTCHA).
Directing them to a specific page there would require support for that (e.g. the login form supporting a "go to page X after login" parameter).
I'm trying to create an HTML page, and a part of it is to check if a user has an active Azure AD logged in session. If so then certain elements of the page would change.
The IdP and SP are setup correctly, and SSO works, this is a separate page from both of them.
This page is here before the user is redirected to the service provider. I just can't figure out how to do this! Is there any way to do it without redirecting the user off the page, maybe using JS?
After passing the aad authentication, you will get the access token.
You want to determine whether the azure session is valid before sso authentication. Then in your html page, if you include access token information, you can judge whether the tokens are valid and expired.
If the html page does not contain token information, it is recommended to use ropc flow to obtain the access token again. If you have to judge whether it has expired, it is recommended to store the information when logging in and verify it next time you log in.
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 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.