I'm trying to password protect a page that contains confidential information.
Upon clicking a link, user will be shown a pop-up dialog to enter password.
If successful, redirect user to page. Otherwise, display "Wrong password".
The thing is, this can be easily overcome if user just copies the URL and add "/exec#ConfidentialPage" to the end of the URL.
Any suggestions?
If at all possible I would highly discourage implementing your own authentication system and instead rely on Google login to secure your data. See https://developers.google.com/appmaker/security/secure-your-app. My short recommendation is to:
Create a google group which contains the users you want to access the
data.
Create a role in App Maker which contains that group
Restrict access to both your data and your view to members of that role.
This is much more secure than a password based approach as #1 It's implemented by Google (implementing your own auth correctly is hard) and #2 You have a list of everyone who has access to your data in the form of the Google group.
Related
What I want
I have a list of people with all their personal information (name, first name, date of birth, email, etc.). I created an account for each of these people using their email/phone + a password I generated for them.
I want to send to each of these people an email/SMS with a link allowing them, once clicked :
to be directly connected on our website, without having to type a password or using a third party as Google/Facebook/etc.
and I want the link not to expire after the first use. The user must be able to click on it several times and be connected to our website each time.
What I tried
This is what I tried so far, unsuccessfully :
Passwordless Auth with email link: using both backend and frontend. Doesn't fit my needs because the signin link works only once by design.
Create a custom token with Firebase: as I understood, the token will expire 3600 seconds after creation, which is not useful for me.
Implement anonymous auth: it still need the user to type email+password at some point if you want to convert the anonymous account to a permanent account (because I don't want to use Google/Facebook/etc auth). Plus, it will need consequent changes in all my website code to work.
At this point I realized that Firebase doesn't have a solution that fits my needs. I started to fiddled around as best I could.
The idea
It works as the following:
First I create an account for the user in Firebase + a unique document in a collection in Firestore. That document contains 3 fields: magic_token, email, password.
Then, I create a link to our website with a unique token as a parameter in it. I store the token as magic_token in the document I described above. I send the link to the user.
The user clicks on the link, get redirected to my website. In the front, I detect the presence of the token in the parameters of the URL, I retrieve the document in Firestore with the corresponding token.
Using the email and password stored in this document I call: signInWithEmailAndPassword() to login the user.
PROS:
it fits my needs.
it is easy to implement
CONS:
the user password is visible in Firestore.
it's not very secure.
The question
Is there a proper way to implement a Magic Link that fit my needs? If not, how can I improve my own custom token authentication ?
I have 2 different websites
-> webgrants.com
->calgrants.com can be accessed directly or from webgrants
there is link provided for calgrants.com in Webgrants.com
so how can i validate the credentials of user when they click on the link provided. how can i do this .urgent please
There might be better ways to do it, but off the top of my head you can do this:
Assuming they have access to the same(or a common) database you create a table of userId and ticket.
Whenever a user wants a redirection to other website, you create a random value(ticket) and assign that value to the user and store this pair into the database.
You add this ticket to address of the other website, as a parameter. Other website checks the table for that 'ticket' and authenticates the user.
I have a very basic understanding of ASP.NET and I am trying to do the following. I have a home page that is set-up to be a login page. If you could just picture a username and password box that is the extent of that home page. Once the user is logged in they will go to a different page let's say the account page. However, when the user clicks the logo at the top left hand it takes them to the home page again but it shows the username and password boxes again ready to be filled.
The user status at the top of my page still shows that the user is logged in. What I am trying to do is add a piece of code that will change the link of the logo to display the account page once they are logged in and not the login page.
I don't know if this can be done through the web.config file since I read a different article that has something similar to this or if this code can be put directly next to the code where my logo link (default.aspx) sits.
Many thanks in advance!
Research the Membership Provider.
It's an industry standard in ASP.NET session management. It will manage all of your pages and allow you to customize pages, menus, etc. based on roles and permissions. Don't reinvent the wheel if you have the oppertunity to use it.
Straight from MSDN:
ASP.NET membership supports facilities
for:
Creating new users and passwords.
Storing membership information (user
names, passwords, and supporting data)
in Microsoft SQL Server, Active
Directory, or an alternative data
store.
Authenticating users who visit your
site. You can authenticate users
programmatically, or you can use the
ASP.NET login controls to create a
complete authentication system that
requires little or no code.
Managing passwords, which includes
creating, changing, and resetting them
. Depending on membership options you
choose, the membership system can also
provide an automated password-reset
system that takes a user-supplied
question and response.
Exposing a unique identification for
authenticated users that you can use
in your own applications and that also
integrates with the ASP.NET
personalization and role-management
(authorization) systems.
Specifying a custom membership
provider, which allows you to
substitute your own code to manage
membership and maintain membership
data in a custom data store
Let's say I have an ASP.NET web application. I create an aspx page that shows a table containing users and email addresses. The user data is stored in a database, and when the page is requested by a logged-in user, html is generated to display the data. If the users requesting the page are not logged in, they are redirected to a sign-in page.
All of this is very standard.
My question is, is there any way the personal data could end up being indexed by a search engine (besides someone hacking into the site or an evil user publishing the data somewhere public)?
What if there was no requirement that users log in? Would the data then be indexed?
In general, search engines should index exactly whats visible to the public visitors, google will be angry with you if you'll expose something different to their spiders.
if you want to control the pages that are indexed on you server check out: http://www.robotstxt.org
If the users don't have to login to access the data, then I see no reason why a search engine could not get access to it. Your data will be indexed if it's not protected by a login.
If there's a login mechanism, it will not be indexed.
IMO you should remove the login requirement from the profile page and also make a sitemap to give a list of users to the search engines. You should prevent guest from viewing users' extra information only.
I am writing a web app for a client. Users will have a one-time key that they will use to initially identify themselves to the app. Once the app verifies that the key is valid it will take them to a page where they can create a normal account to use for all subsequent logins. The create-account page should only be accessible after entering the key and shouldn't be accessible otherwise. I.e, it shouldn't be accessible to users logged in with a normal account.
This is asp.net 3.0 using a custom membership provider.
My plan is to create a temporary account based on the key and authenticate the user with that account. This allows them access to the create-user page (which is protected with a location tag ) where they can create the formal account. I then authenticate them with their new account and delete the temporary account.
The flow is: the user goes to a page where they enter the key. If the key is valid I create the temporary account, call FormsAuthentication.SetAuthCookie, and redirect to the create-account page. This all works, although it seems a little complicated.
The problem is that the create-user page is available to any authenticated user; I only want it available during the time between entering the key and creating the formal account. So I thought I'd create a special role for the temporary account and make the create-user page accessible only to that role and none other. I created my own Principal object with a special role and tried setting it when I authenticate the temporary account but I can't get that to work.
I'm really hoping I don't have to write a custom role provider just to do this.
How can I make this work? There's gotta be a simpler way!
Why not simply create the real account when they enter the key. Assign it some random name and then let them change the name and other details. Then you don't need the create user page, just the enter key page and an account details editing page. If you're concerned about getting the account details filled in, you could set it up (perhaps via code on a MasterPage) so that incomplete accounts always get redirected to the edit details page until the details are entered.
Or, you could have them enter the required details in addition to the key code on the enter key page and simply use those details when creating the account.
My advice would be to avoid the use of temporary accounts when validating the user. Instead, generate your own logic for validating the sign-up key. Then, at the head of the page, you can check whether the user is an authenticated user (SetAuthCookie has been called) and jump to a different page if this is true.
You may even be able to change the page access to forbid this page to authenticated users (I know you can disable accounts for unauthenticated users but I'm not sure if you can go the other direction).
The key, though, is to avoid relying on the membership provider when, in fact, the user is not yet a member!
Assign an "incomplete" role when authenticating against the temporary token, then restrict access to only that role... when the account is created, send them to a re-login page (terminating the authentication token). This will simplify your security model.