I'm using FirebaseAuth.createUserWithEmailAndPassword() for register and FirebaseAuth.signInWithEmailAndPassword() for login.
After doin that, FirebaseAuth.getCurrentUser() is never null, only after doin a FirebaseAuth.signOut().
So the questions is: how to intercept if account password has been changed?
firebaser here
Firebase Authentication doesn't fire any event when a user changes their password.
You can of course catch most changes by embedding the firing of an event into your own application code. But that can be circumvented by users willing to spend the effort.
So there currently is no reliable way to detect whenever a user changes their password. I'd recommend that you file a feature request, since those do often help the team determines priorities.
Related
I want to make an JavaFx application where you can login. I already have a file with the encrypted password and all in all the login already works. But now I don't know how to check if the user is logged in, while he is doing something. Just set a boolean in the main class to true? I don't know hot to do this. Maybe you can help me.
It seems pretty simple,
First of All You will receiver the Information of the User and Will store that information such as User name and Password in variables and then you will check from database whether User Exists or not.
I will suggest you to not discard these variables whether user has successfully logged in or not.
Then you can also use these variables to do communication in other Stages or Scenes.
Making it simple, store Information in variable and don't discard them.
That's it.
Here is the premise, I am not allowed to use JavaScript or Cookies for this website.
However I do not wish to ask the user for their password for every essential task that requires their password for at least 15-30 minutes.
I also don't like the idea of saving their password to a temp file in case the program dies and is not able to erase it as scheduled.
So my plan is upon first contact, assign the user a unique randomly generated secure id/hash and attach it inside their generated HTML. And server side match their password to their id inside the ServletContext. This way for all their incoming requests I can match them without asking for password across all classes.
Also I will make sure to automatically erase their info from the ServletContext when their 15-30 minute expires.
So far it seems like to me this method avoids both JS and Cookies, also all the external storage methods that are at risk when the program dies. Yes the ServletContext is supposed to be global, but without their unique temporary id/hash no one will be able to impersonate them.
I am asking this question because I couldn't find anyone else asking the same question so I needed to make sure there isn't anything wrong with this method.
Given the following restrictions:
No cookies allowed.
No JS allowed.
Caching credentials at client-side is not an option.
The proposed approach seems ok at first glance. However, I would suggest that you follow this guidelines:
Make sure replay attacks aren't possible. Since you can't hash and sign request at client-side, invalidate and refresh the tokens frequently (preferably with each request) at the back-end.
CSRF counter-measures should be in place.
SSL should be enforced.
I did oauth2 authorisation on some site. This is classical way with WebView and page there, where user adds password and login, presses Allow button etc. Then it gets refresh_token and by another POST message gets auth_token, which I have to store (in AccountManager) and user later.
Can I do this with the help of AccountManager? How can I do this?
I wonder if user should enter a login and password twice - one for account manager (when I should create it), and other in WebView form?
I just need to use AccountManager in order to sync data lately.
Don't know if you still looking for a solution on this.
Short answer it's yes u can this example may give you the inspiration you need : https://github.com/learning-layers/android-openid-connect It goes a little futher supporting OIDC workflow.
The author is working on a lib maybe it's worth looking for this release.
I am creating a RESTful web service and I try to follow the conventions and recomendations for creating a good web service. Now I have come to a halt though. I have a User entity in my system that I have regular CRUD paths for. I want to expose an API to deal with forgotten passwords. It will take a username in the request and then check if it finds the user. If it does it will change the password and change the password to the autogenerated one and send an email to the user.
I read this: RESTful actions/services that don't correspond to an entity? and I see that I maybe should start looking at non database entities as resources also.
But I still have issues with finding a concept for forgotten passwords in my API.
What could I name the path and what HTTP method is appropriate for it? Should PUT be used since it will update the user with a new password?
I want to expose an API to deal with forgotten passwords. It will take a username in the request and then check if it finds the user. If it does it will change the password and change the password to the autogenerated one and send an email to the user.
If you really want to be RESTful:
What could I name the path and what HTTP method is appropriate for it?
It is not a PUT nor a GET, since they are idempotent methods (meaning you executing them once or 10 times should give the exact same outcome) and what you want is not: if requested 10 times, 10 different passwords will be generated.
There are other reasons, but the above is simple and leave no doubts. So a POST it is.
About the URL, since password can be considered a subresource (a part of) of user, considering the URL for the user resource http://www.example.com/rest/user, it makes sense to design the password URL as:
http://www.example.com/rest/user/password
This way, if someone wants to set the password, he should send a PUT to that URL with the new password (idempotent behavior!).
Now the a password reset action, I'd make it a POST to that URL, possibly with some more specific content like password-reset and some necessary keywords (the answer for a secret question, maybe) in the POST body. If that content does not come, a 400 Bad Request response would be appropriate. If the requester tries too much, a 403 Forbidden should be issued during the "retry-wait-period". Needless to say, both the PUT and the POST should take place within a secure, encrypted (HTTPS, anyone?), channel.
I think that your approach has obvious weakness. Think that you expose URL that generates new password for user, for example: POST to URL http://mycompany.com/app/user/foobar/resetpassword
Obviously this URL cannot be password protected: otherwise use that forgot his password cannot reset it. OK, this means that everyone that knows the user name can reset password of the user. Even every 5 seconds. Or milliseconds... Cool!
This means that you have to somehow protect your system from such "naive" hacker's attack.
I recently implemented similar system and can suggest you my solution.
Expose open URL that allows to start the process, e.g. http://mycompany.com/app/user/foobar/resetpassword. This URL does not change the password. It just creates email that contains yet another clickable URL like http://mycompany.com/app/user/resetpassword/UNIQUETOKEN. The token is something that you cannot guess.
User receives the email and clicks the link. This time the password is changed and appropriate email is sent to the same email.
This mechanism protects your system from naive hacker's attack and from occasionally pressed "reset password" button because the first action does not actually change password. Only user that can access his email can indeed change password.
Concerning the token generation. The best solution is to store mapping of token to password change request in DB, so you can limit click attempts and make request expiration timeout. I implemented simpler solution for some reasons: the token actually contains encrypted user name and date when password was requested, so I implemented the request expiration but cannot limit number of clicks on the token contained URL.
However the implementation is very simple and stateless.
I'm currently researching the best method of solving an issue I'm having and was wondering if you could help.
I have a user profile section in my website that I want to make a bit more secure.
I have an issue where when a user logs in, if they click the back button it takes them back to the login page but they're still logged in. How can I have it log the user out and take them to the logout page?
Thanks for your help
I'm not sure you are trying to do the right thing. Users know and use the back button, and it is helpful to them if that button takes them back to what they were doing beforehand. Having it automatically log users out breaks some basic assumptions about how web applications work, and I don't recommend that you do this.
Also, the problem is worse than you think it is. You mentioned users who use the back button, but what about users who use right-click-open-in-new-tab to open several tabs viewing your application, then switch back and forth between the tabs?
That being said, here is a way you can achieve what you want. You need to track most-recently-viewed-page in the user's session on the server. Each time you get a new request, compare against the cached value in the session and if it's not a page that could have navigated here, clear out the session and display the login page. Another way the same thing is achieved is to generate a key as each page is displayed (a large random number will do) which is passed on the subsequent request, and when any page is requested and it doesn't have the most recent key then clear the session and display the login page.