I want to use basic auth to authenticate users. The problem is when a user needs authentication, the browser loads an ugly form where the user should enter their credentials (such is the default on all browsers when they get a basic auth request).
I would like to know how I can bypass this ugly browser default form and instead serve an alternative good looking custom made form.
Thanks in advance
What you're seeing is the HTTP authentication page put out by your web server. Browsers just pass it as is, and it's not customizable. This is why no one really uses them for much other than locking a site down during development or hiding a particular part of a site.
If you want to do something that fits the look and feel of your site, you're going to need to design a page or include your login somewhere on your existing pages.
Related
I am developing a MERN app, where users share things with a link to access those things.
So these things get displayed to other users, and they can click on them, and they get redirected to that link.
This doesn't seem secure as some users can post things with malicious links.
Is there a way to verify that a link is secure and so validate the thing before it gets posted?
This isn't possible in an automated way. Links don't include any information about themselves other than the URL they point to.
You need a list of "malicious" URLs to compare against in order to achieve this. There are services that provide such databases. But this is a never-ending game of cat-mouse.
For example, if I have a malicious website, I don't have to share the URL to my website directly, I can use URL shortener service (bitly for example) that then redirects users. This way, I easily circumvented your protection.
That's the reason browsers have their own "malicious websites" list, since they have access to the final URL you're visiting.
In short: no, there's only limited protection you can offer.
The best you can do is warn the users they're leaving your site, like Discord or Facebook do (and they do that because they can't solve this problem either).
I am working on the logout part of my website and I am using JWT for authentication and using cookies to send the JWT for client side.
For logging out I am passing some dummy token value with the same token name so that it over rides the previous token. But when I log out of the portal, I am still able to access my dashboard. There is some glitch in the logout functionality. I guess it is due to the browser cache.
I have few questions regarding Express.
Are there any ways to reload the current page using Express and delete the browser cache while doing so?
I need to disable the browser forward option of chrome once the user is logged out, how can I achieve this using express?
How to redirect the user to his dashboard when he tries to hit '/login' or '/signup' route when he is already logged in? I am using the JWT authentication for login
Thanks in advance
Are there any ways to reload the current page using Express and delete the browser cache while doing so?
The server can't, on its own, tell the browser what to do. The browser has to initiate communications and then act on that communications.
You could have the web page in the browser reload its own page using Javascript with window.location.reload(true) at any time. If you want the web page Javascript to be told when to do this by the server, it could either send regular Ajax calls to the server and, based on the response, decide when to reload the page. Or, it could have a webSocket connection to the server and the server could send the web page some data that, when the web page received that data, it would see that it should reload its page.
We could help you better if you told us what the real problem was here. Web pages can use Javascript and/or webSocket connections to dynamically update themselves rather than just reload all the time. That's a more modern design.
I need to disable the browser forward option of chrome once the user is logged out, how can I achieve this using express?
There's a discussion of disabling the forward button here: HTML5 history disabling forward button. You will probably find this is a brute force approach (it involves getting rid of browser history) and there is likely a much better way to solve whatever real problem you're trying to solve. It also sounds like you may also want to manage browser cache expiration too.
How to redirect the user to his dashboard when he tries to hit '/login' or '/signup' route when he is already logged in? I am using the JWT authentication for login
When you detect a request to '/login' or '/signup' in Express from a user who is already logged in, you just respond with a res.redirect("/dashboard") from your server. FYI, there are lots of questions about whether this is the proper user experience. A user going to '/login' or '/signup' when they are already signed in could have any one of these use cases:
They don't realize they are already signed in or they don't know if they are signed in as the desired user.
They want to sign in as a different user.
They want to create a new account (different from what is currently logged in).
They are trying to figure out how to log out.
You should make sure that blind redirecting (and not taking the user to the page they asked to go to) still makes all these use cases entirely clear. If not, you will just frustrate the user by not taking them where they asked to go.
I have a website protected by basic auth, so when someone hits it, they get a standard username/password box. This website is accessed often from shared computers.
Is there any way to prevent the various "Remember my Credentials" functionality on browsers? I would like to prevent any browser from saving this username/password in any client-side repository.
I realize this is purely a function of the browser, but is there any commonly-accepted HTTP header or any other method of asking a website not to do this?
The answer is no. I'm really sorry but even if you could do this how would you stop an independent add-in from scraping web sites for username and password boxes and then storing that information.
Even if this were possible in code it could be easily circumvented by simply ignoring any directives you give. Thus rendering such headers pointless.
As stated before it is not possible to circumvent a browser feature it could easily save the credentials before it sent the POST thus stopping anything on the server from preventing it being cached.
I have a page that contains sensitive information that I would like to require reauthentication in order to load. I am using Classic authentication mode, not forms.
The first method i looked at was the PrincipalContext.ValidateCredentials method, but that would require sending login details in plain text (i think).
I have thought about using javascript to turn off cookies so they would have to log back in, but I haven't thought of a way of doing this well.
Has anyone done this before with SharePoint?
what i ended up with:
a web part on the page with sensitive material which forces an HTTP 401, and then redirects to another page.
this other page has a second web part, which then redirects back to the original page after setting some session variable.
You could use something along the lines of this if you're using IE6/8 but other browser may have issues with it (look into http-keep-alives).
<script type='text/javascript'>
document.execCommand("ClearAuthenticationCache");
</script>
That said, it doesn't seem like friendliest UI option to forcibly clear someones authentication. I suspect a better option would depend on the audience and if they are on a trusted domain or coming from an external source. If they are on the trusted domain and don't normally login anyway, this approach likely wont please them much.
Is it possible to secure only the Login.aspx page (and the postback) and not the whole site in IIS?
We are looking to do this specifically with a SharePoint site running Forms Based Authentication against our Active Directory.
Links to this will be helpful.
This is what we have done so far:
1. Setup SharePoint to use FBA against AD.
2. Moved Login Page to Secure/Login.aspx
3. Set the appropriate Login url in web.config as https://..../Secure/Login.aspx
This is not working and help is needed here.
However even if this works, how do we get the user back to http from https?
There's not a whole lot of point. If the only thing that's encrypted is the Login.aspx page, that would mean that someone could sniff all the traffic that was not sent through the login page.
Which might prevent people from getting user:pass, but all your other data is exposed.
Besides all the data which is exposed, and the user's operation which can be changed en route, the user's session id (or other authentication data) is sent in the clear. This means that an attacker can steal your cookie (...) and impersonate you to the system, even without getting your password. (If I remember correctly SPSv.3 also supports builtin password changing module...)
So I would say that this is not a Great Idea, unless you dont care about that system very much anyway.... But then, why bother with authentication at all? just make it anonymous?
I agree with AviD and Dan Williams that securing only the login page isn't a great idea because it exposes other data after leaving the password page. However, you can require SSL for only the login.aspx page via the IIS Manger. If you navigate to the login.aspx page in IIS Manager (I believe it's under /_layouts), you can right-click on the individual file and select Properties. From there, go to the File Security tab and click on the Edit... button under Secure communications. There, you can check the Require secure channel (SSL) box, and SSL will be required for that page only.
I'm not positive about getting the user back to http from there, but I believe its default behavior is to send you to the requested page if the login is successful. If not, I would think you could customize where the login page sends you on a successful login.