I'm currently working on authentication using Firebase's signInWithEmailAndPassword().
I want to check if a user logins in for the first time and recently found isNewUser.
The problem is, it always returns false because signInWithEmailAndPassword() runs in first place, making isNewUser false automatically.
Note) I don't use createuserwithemailandpassword() for registration. I manually make an account and provide it to the user.
Any suggestion?
firebase
.auth()
.signInWithEmailAndPassword(email, password)
.then(user => {
if (user.additionalUserInfo.isNewUser) {
// Want to redirect to Terms of service
// But it always returns false
}})
When you create a new user account with createUserWithEmailAndPassword () that user is immediately signed in. That is the only time when additionalUserInfo.isNewUser will be true.
I just noticed that you create the account out-of-bounds without calling the API. I'd still expect this same reason to be true though. You should be able to verify that through UserMetadata, which you can get from the User object.
Related
What could cause specific users to have their local storage cleared, but the rest of the users are unaffected? Is it their firewalls? Is it their anti-virus? Browser? Browser version?
Any help would be greatly appreciated.
The application -
I have a website that requires login. Certain routes require the user receive a token(from the login step) if not they will be redirected to the login page.
The run down-
Two users have come forward and mentioned they couldn't log in. After some trouble shooting and looking at logs I found they were successfully logging in. So I screen shared with one user and I watched the localstorage in the dev console. I saw that they acquired a token successfully. Then they go to navigate to the myorderCards page and suddenly the token is cleared from the storage and they are routed back to the login page. This then puts them in a loop because every time they login successfully I have a return parameter which sends them back to myorderCards which then clears the token etc...
So the problem I am facing is that I can not recreate this issue. I have tested locally and on the published site. I have tested on and off network. I have tested 3 different browsers and even tested on a mac device(the two users in question are using macs) This issue only happens for the two users that have submitted a ticket. Still I can not figure out how the local storage is clearing. the only place that clears the token are the two lines you see below.
Additional Information-
I have tried changing my browser settings to have a high security setting. However, it continues to work for me. I have changed the browser settings to not allow cookies at all but that breaks the entire website.
P.S there are no errors or exceptions to go off of. Either on the server or the browser side.
app.module.ts
RouterModule.forRoot([
{ path: 'myorderCards/:id', component: MyOrderComponent,canActivate:[MyAuthGuard] },]),
In auth guard class
canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<boolean> | Promise<boolean> | boolean {
const token = this.storage.getLocalStorageValue('mycurrentUser');
if (token != null && Object.keys(token).length != 0) {
const exTime = token.expires;
if (new Date(exTime.toString()) > new Date(Date.now())) {
return true;
}
else {
this.storage.clearLocalStorage('mycurrentUser');
this.router.navigate(["/mylogin"], { queryParams: { returnUrl: state.url } });
return false;
}
}
else {
this.storage.clearLocalStorage('mycurrentUser');
this.router.navigate(["/mylogin"], { queryParams: { returnUrl: state.url } });
return false;
}
}
}
Your token's expiration time comparison isn't timezone agnostic.
The issue is: If, one way or another, your token includes a time that doesn't provide its timezone assumption, like 9/13/21 5:30 PM (or epoch format not based in UTC), then it would already be expired to the end user who's 1 hour ahead of you. Etc.
As a solution, you could provide all datetimes in UTC, and even then convert it to Unix epoch to discourage people trying to manually 'read' it in their local time.
But for OAuth2, it's more common to include 'expires in' rather than 'expires at'. So the body of an OAuth2 access token is typically this:
{
"access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
"token_type":"bearer",
"expires_in":3600,
"refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
"scope":"create"
}
expires_in is how long (seconds) the token is valid/alive. When the client receives this token, they assume it expires that long from 'now' (where 'now' is subjective depending on geography). So they calculate the expiration date/time themselves and store it, which sidesteps the issue of timezone conversion altogether.
Then, for two customers authenticating at the same time, one in New York may store 6:00 PM while the one in Chicago may store 5:00 PM as an expiration date, even though they both expire the same moment.
Created email-verification that takes a user to a verification page. Code to change isVerified is verifyUser.vue
this.verifyToken({
action: "verifySignupLong",
value
})
Where value is the Token
In users on the server have isVerified() on before->get and find
But when verifyToken is ran it tries to find the user and fails at isVerified. How do I get verifiedToken changed from false to true before running verifySignupLong
users does not verify email-verification. Authmanagement does.
I developed a chrome extension using Rally's WSAPI v2.0, and it basically does the following things:
get user and project, and store them
get current iteration everytime
send a post request to create a workitem
For the THIRD step, I sometimes get error ["Not authorized to perform action: Invalid key"] since end of last month.
[updated]Error can be reproduced everytime if I log in Rally website via SSO before using the extension to send requests via apikey.
What's the best practice to send subsequent requests via apikey in my extension since I can't control end users' habits?
I did see some similar posts but none of them is helpful... and in case it helps:
I'm adding ZSESSIONID:apikey in my request header, instead of user /
password to authenticate, so I believe no security token is needed
(https://comm.support.ca.com/kb/api-key-and-oauth-client-faq/kb000011568)
url starts with https://rally1.rallydev.com/slm/webservice/v2.0/
issue is fixed after clearing cookies for
https://rally1.rallydev.com/, but somehow it appears again some time
later
I checked the cookie when the issue was reproduced, and found one with name of ZSESSIONID and its value became something else rather than the apikey. Not sure if that matters though...
code for request:
function initXHR(method, url, apikey, cbFunc) {
let httpRequest = new XMLHttpRequest();
...
httpRequest.open(method, url);
httpRequest.setRequestHeader('Content-Type', ' application\/json');
httpRequest.setRequestHeader('Accept', ' application\/json');
httpRequest.setRequestHeader('ZSESSIONID', apikey);
httpRequest.onreadystatechange = function() {
...
};
return httpRequest;
}
...
usReq = initXHR ('POST', baseURL+'hierarchicalrequirement/create', apikey, function(){...});
Anyone has any idea / suggestion? Thanks a million!
I've seen this error when the API key had both read-only and full-access grants configured. I would start by making sure your key only has the full-access grant.
To check if the view of a user is working or to make change out of the users view point (in development) it can be quite useful to incarnate a certain user.
How would I do this with Meteor? Best would be a solution which is independent of the Account Authentication.
To impersonate a user in production, you can call setUserId on the server, and Meteor.connection.setUserId on the client. For more details, see my blog post.
If you're using Meteor.userId() and Meteor.user() to identify your person in your javascript you could use something like this to override it at the very top of your client js
Meteor.userId = function (impersonate_id) {
return (impersonate_id) ? impersonate_id : Meteor.default_connection.userId();
}
Meteor.user = function (impersonate_id) {
var userId = Meteor.userId(impersonate_id);
if (!userId)
return null;
return Meteor.users.findOne(userId);
}
And now when you use Meteor.userId or Meteor.user modify your code so everywhere you use Meteor.user & Meteor.userId accepts an argument. So when you want to impersonate a user just pass it argument of the _id of the user you want to log in as
Meteor.user("1"); //Loads the data for user with _id 1
Meteor.user(); //Loads the actual logged in user
Also this will only work if you're actually the admin and your publish function allows you to see all your user's data
I have a username/password on a login page, which goes to 'member' page. Basically, I used a statement that finds the number of rows in a SQL query, and if it's not 1 (the correct username/password combination), then it redirects back to the login page.
However, on the 'member' page, there are forms to do various things, like add new rows to a table using SQL, or return queries of joined tables. These forms also link back to this 'member' page, but the conditions for logging in (which requires a username variable and password variable) would no longer be met.
So, how do I get the server to remember whether a user is logged on or not?
In the application.cfm or application.cfc, you will need to enable sessionManagement = true so you can start tracking variables across page requests. Then when a user logs in, you will set a variable like isAuthenticated = true. Only redirect to the login page if the isAuthenticated = false or undefined (you can set a default using cfparam in onSessionStart of Application.cfm)
Rough example, assuming you are using ColdFusion 9+
Application.cfc
component {
this.name = 'myApplication';
this.SessionManagement = true;
public function onSessionStart() {
param name='session.isAuthenticated' default=false;
}
}
checkAuthentication.cfm
<cfscript>
if (!session.isAuthenticated) {
// send to login page
}
</cfscript>
In your login processing page, make sure you set session.isAuthenticated to true, and then it should skip checking / asking for the login. You can also look into the built-in authentication functions of CFLOGIN.
Hope that helps a bit.