I am trying to implement magic link login to my app. I enabled email login option through Firebase console and localhost is already under the authorized domains. I have the code snippet and the screenshot in the below.
I can see that some request is being done with 200 success code but I receive no email.The code does not throw any error and I have no idea what is wrong at this point. Can someone help?
export const sendMagicLink = (email: string, redirectUrl: string) => {
const auth = getAuth(getClientApp());
const actionCodeSettings = {
url: redirectUrl,
handleCodeInApp: true
};
return sendSignInLinkToEmail(auth, email, actionCodeSettings);};
const handleSubmit: svelte.JSX.EventHandler<SubmitEvent, HTMLFormElement> = async ({
currentTarget
}) => {
email = new FormData(currentTarget).get('email') as string;
const redirectUrl = `${window.location.origin}/auth/confirm`;
state = 'submitting';
try {
await sendMagicLink(email, redirectUrl);
setMagicEmail(email);
state = 'success';
} catch (error) {
if (error instanceof Error) {
state = error;
} else {
console.log(error);
state = new Error('something went wrong sending the magic link 😞');
}
}
};
Request body:
canHandleCodeInApp true
continueUrl "http://localhost:3000/auth/confirm"
email "someemail#gmail.com"
requestType "EMAIL_SIGNIN"
Intuitively a developer assumes that emails sent out by Firebase's internal email service will not be classified as spam, but this happens very often.
To solve this, one would need to:
Setup a custom domain for Authentication in Firebase Console
Go to Firebase Authentication
Go to Templates
Go to Email Address Verification
Click Edit
Click Customize domain and go through the whole process
Setup a proper SMTP server in Firebase Console
Go to Authentication
Go to Templates
Go to SMTP Settings and enter SMTP Settings. Use the same sender domain as has been used in Email Address Verification above.
Setting Action URL
Set your custom domain in the Hosting section, first, e.g.: example.com.
Then, in the Authorization Templates section, click Edit and adjust the Custom Action URL at the bottom of the page. Set it to the same domain used for Hosting, e.g.:
https://example.com/__/auth/action
This helps to decrease the spam ranking of the emails, as the outgoing email from domain A will now contain a link to domain A.
In contrast, an email from domain A carrying a link to domain B is more suspicious.
Related
I do have a super weird error coming up only when deploying the code to Vercel. It doesn't happen locally which makes it quite annoying to begin with.
I do have a staging and a production instance for my code. I want to protect the staging with a password which is not difficult since I implemented the authentication via Firebase. The only tricky part is that I don't use Firebase to keep track of the user but my server (basically setting a cookie). I should mention that I am using Sveltekit to put it all together.
In sveltekit you can use hooks, which can be seen as middlewares, to redirect a user to the sign-in page if the env variable for the environment is set to dev.
Another hook redirects a logged-in user, so if you are already logged in and try to go to auth/sign-in or auth/sign-up you'll get redirected to the home page.
Now the weird happens: I go on the deployed version of the site, and I get immediately redirected to the sign-in page, which is correct. I try to navigate to all the pages of the website, the redirect still works fine. I log in and upon success, I should be redirected to the homepage, which I do BUT the home page redirects me to the sign-in page as if I wasn't logged in and again the sign-in page redirects me to the home page as if I was, thus creating a loop.
I honestly don't know why this happens since it perfectly works locally, so my thoughts go to Vercel. I would exclude Firebase since I remembered to put the custom domain as an allowed domain in the settings.
To give a bitmore context, I structured the hooks responsible for the redirect in this way:
export const authSessionHandler: Handle = async ({ event, resolve }) => {
const cookie = event.locals.cookie;
const idToken = await getIdTokenFromSessionCookie(getCookieValue(cookie, 'session'));
const user = idToken
? {
uid: idToken?.sub,
email: idToken?.email
}
: null;
event.locals.idToken = idToken;
event.locals.user = user;
return resolve(event);
};
export const redirectLoggedInUserHandler: Handle = async ({ event, resolve }) => {
const { user } = event.locals;
const next = event.url.searchParams.get('next') || '/';
if (
user &&
(event.url.pathname.startsWith('/auth/sign-in') ||
event.url.pathname.startsWith('/auth/sign-up'))
) {
return new Response('Redirect', {
status: http_302.status,
headers: {
location: `${next}`
}
});
}
return resolve(event);
};
export const redirectToSignInForDevEnvironmentHandler: Handle = async ({ event, resolve }) => {
const { user } = event.locals;
const allowedEndpoints = ['/auth/sign-in', '/auth/session'];
if (!user && env === 'dev' && !allowedEndpoints.includes(event.url.pathname)) {
return new Response('Redirect', {
status: http_302.status,
headers: {
location: '/auth/sign-in'
}
});
}
return resolve(event);
};
The handlers are in that order, so the first one populates the user and the rest can check the rest.
In the code I am getting the user from event.locals which kind of decides the entire logic (as it should) and to me it's quite interesting and telling the fact that the sign-in page redirects me to home which mean the user is defined, but the home page redirects back as if the user was not defined. This made me think it is not a problem with the code but probably the provider(s) Vercel or Firebase.
It would be very helpful to know your thoughts about it.
Hello! I am OCD about security for my app and was wondering how to properly login/signup a user with the Google auth provider.
I have a client ID and secret for that client ID - from Google Credentials - for my app. I know not to put the secret in the client.
The code below works perfectly but I'm unsure if it's safe to generate an id_token for a user directly without any server code because of this doc from Expo Go:
Notice it says "be sure that you don't directly request the access token for the user". I don't know what this means exactly.
const [request, response, promptAsync] = Google.useIdTokenAuthRequest({
clientId:
"my-client-id-goes-here.google.apps.com",
});
React.useEffect(() => {
if (response?.type === "success") {
const { id_token } = response.params;
const credential = new GoogleFirebase.GoogleAuthProvider.credential(
id_token
);
}
}, [response]);
Any ideas on how to execute this securely to make sure a user can't change the URL redirect parameters from Google or anything? I'm just not 100% on what I'm doing here.
Use an .env file to store your sensitive information. For example in your .env file put
CLIENTID="my-client-id-goes-here.google.apps.com"
Then call it like you did above:
const [request, response, promptAsync] = Google.useIdTokenAuthRequest({
clientId:
process.env.CLIENTID,
});
I made a spotify clone which have a login,main pages. The user is initially directed to login page (localhost:3000/login) and once the user clicks login button they are taken to spotify authentication callback url (from spotify side, we can login using google, facebook or email etc) and once the user is logged in (successfully authenticated) , spotify provides a token which is used to check if the user is authenticated from client side. If success, the user is taken to the main page (which has all the music in it).
The spotify dashboard takes in redirect url for authentication which in my case its -> http://localhost:3000/api/auth/callback/spotify
This workflow worked perfectly when working and running locally ( localhost:3000 ).
When hosting in vercel,
I created a project in vercel without envs
I took my https://sp-app.vercel.app which is the domain and added to NEXTAUTH_URL into my env, and also added - NEXT_PUBLIC_CLIENT_SECRET, NEXT_PUBLIC_CLIENT_ID and JWT_SECRET
Went to spotify dashboard and editing the redirect url to https://sp-app.vercel.app/api/auth/callback/spotify and saved
redeployed the app from vercel (which gave me a deployent url, but nevermind) and clicked on the domains --> sp-app.vercel.app
The login page came, once I clicked on login button, it loads and stays in login page itself. It isn't moving to my home page nor authenticating but this same code worked locally fine.
Code to understand :
Login button:
{providers !== null && Object.values(providers).map((provider) => (
<div key={provider.name}>
<button onClick={()=>signIn(provider.id, {callbackUrl:"/"})}
>Login with {provider.name}</button>
</div>
}
export async function getServerSideProps(){
const providers = await getProviders(); //getProviders is imported from next-auth
return {
props:{
providers,
}
}
}
middleware:
export async function middleware(req){
const token = await getToken({req,secret:process.env.JWT_SECRET});
const {pathname} = req.nextUrl;
//Allow the request if,
// (1) Its a request for next-auth session & provider fetching
// (2) The token exists
if(pathname.includes('/api/auth') || token){
return NextResponse.next();
}
//Redirect to login if no token or requesting a protected route
if(!token && pathname !== "/login"){
return NextResponse.redirect("/login");
}
}
While I checked with Network tab, I get a session which should log me in and redirect to main page, but it isn't working in vercel deployment.
Hey so first off make sure your NEXTAUTH_URL environment variable is correct. Also check that the redirect URI (from the Spotify developer dashboard) is correct.
After that, add this secureCookie code to the getToken function in the _middleware.js file. So that function should end up looking like this:
const token = await getToken({
req,
secret: process.env.JWT_SECRET,
secureCookie:
process.env.NEXTAUTH_URL?.startsWith("https://") ??
!!process.env.VERCEL_URL,
});
Let me know if this works. I had the same exact issue and this worked for me.
First of all, I am using nodejs for the backend. I use firebase hosting and firebase functions to deploy an express() app.
What I am trying to achieve is to make an admin website, which is connected to Firebase. so I have a route /admin/ like this:
adminApp.get("/", (request, response) => {
return response.redirect("/admin/login");
});
Here I basically want to check if a current user is logged in - or not.
I know firebase supports client side authentication using:
firebase.auth().onAuthStateChanged(user => {
if (user) {
} else {
}
});
And using
function login() {
var userEmail = document.getElementById("email").value;
var userPass = document.getElementById("password").value;
firebase.auth().signInWithEmailAndPassword(userEmail, userPass).catch(function(error) {
var errorCode = error.code;
var errorMessage = error.message;
if (error) {
document.getElementById('loginError').innerHTML = `Error signing in to firebase`;
}
});
}
However image this case:
Someone (not an admin) is visiting /admin/some_secret_website/ which he obviously does not have access to.
If I rely on client side authentication, it first loads the entire website and the scripts and then notices - hey I am not authenticated, let me redirect to /login. By then however anyone knows the source code of an admin page.
I'd rather have something like:
adminApp.get("/admin/some_secret_website", (request, response) => {
if (request.user) {
// user is authenticated we can check if the user is an admin and give access to the admin page
}
});
I know that you can get the user's token and validate that token using the AdminSDK, but the token must be send by the client code, meaning the website was already loaded.
I came across Authorized HTTPS Endpoint by firebase, but it only allows a middleware when using a bearer token.
Does anybody know how I can maintain a server side user object to not even return admin html to the browser but only allow access to admins?
Like Doug indicated, the way your admin website/webapp would function with Firebase Cloud Functions (which is effectively a Nodejs server) is that you get the request, then use the headers token to authenticate them against Firebase Auth. See this answer for a code snippet on this.
In your case, I'm thinking you would create a custom claim for an "administrator" group and use that to determine whether to send a pug templated page as a response upon authentication. As far as Authorization, your db rules will determine what said user can CRUD.
In my Meteor.js application, I'm using the accounts-google package in order to be connected with a google account. I have two questions about it.
First, is there a simple way to filter the account used? I would like that the users can connect only with google accounts belonging to my company. Our google account mails end with #mycompany.com. So it would be a simple mail filtering.
I already done that with some post log in hooks but I was wondering if there was a simpler way for doing it.
My second question is how to force the opening of the google account choser. For now, if I try to connect with a wrong google account, and if I only added this account (like in gmail, drive, etc), the google choser doesn't pop and automatically connect with this wrong account. So, in this case, the user is totally blocked (my application disconnect him if he tries to log in with a wrong account but the google account module doesn't propose him to connect with another account).
Thank you for your help.
In order to restrict signup/login to your domain, simply do on the server:
var checkEmailAgainstAllowed = function(email) {
var allowedDomains = ['mycompanydomain.com'];
var allowedEmails = ['otheruser#fromotherdomain.com','anotheruser#fromanotherdomain.com'];
var domain = email.replace(/.*#/,'').toLowerCase();
email = email.toLowerCase();
return _.contains(allowedEmails, email) || _.contains(allowedDomains, domain);
};
Accounts.config({
restrictCreationByEmailDomain: function(email) {
if (!email) {
throw new Meteor.Error(403,'This email address is not allowed');
}
if (!checkEmailAgainstAllowed(email)) {
throw new Meteor.Error(403,'This email domain is not allowed');
}
return true;
}
});
And to login, you'll need on the client:
Meteor.loginWithGoogle({
forceApprovalPrompt: true, //this is what you want, to rerequest approval each time that prompts the google login prompt
loginStyle : "redirect", //or not, depending on your need
requestPermissions : ['profile', 'email'],
requestOfflineToken: true
}, function (err) {
if (err)
// set a session variable to display later if there is a login error
Session.set('loginError', 'reason: ' + err.reason + ' message: ' + err.message || 'Unknown error');
});
Side note:
Alternatively, you can set up your routes so that every time a new route is called, you login, and every time a route is destroyed or on windows's unload, you call logout. This causes login/logout roundtrip everytime the route changes, but you'll make sure that the new user always has a fresh session
Edit:
When you log out of your meteor app, you don't log out of google. That's how oauth works. So, basically, if you want a meteor log out to also log the user out of their google account, so that the next time they come back, they need to provide credentials again, you should do:
Meteor.logout(function(e) {
if (e) {
console.log("Could not log the user out")
} else {
window.location.replace('https://accounts.google.com/Logout');
}
});
This uses the callback of Meteor.logout() so that when the logout is successfull, the user is redirected to google's central account logout url where the user is also logged out of all google services.