Related
I am new to firebase and I am trying to handle firebase user authentication in React.js. I did manage to create users with email and passwords. But, now I would like to send the user an Email link to reset their password.
My code currently look like this.
// This line of code belongs to the top
import { auth } from '../firebaseConfig'
//This part goes under the React component
<p onClick={async () => {
try{
await sendPasswordResetEmail(auth, // My Email Id)
alert('Password reset link has been sent to your email')
}
catch(err){
alert(err)
}
}}
>Forgot your Password ?</p>
However, I do not get any error messages and I do get the alert message that says "Password reset link has been sent to your email." Unfortunately, I didn't receive any email. Note that I have given my own email id as the parameter for testing purposes.
firebaser here
Did you check your spam folder? We recently see a lot of the emails from Firebase Authentication ending up in the user's spam folder or being marked as spam in a system along the way. This is being tracked in this status message on the Firebase dashboard and in public issue #253291461.
To reduce the chances of the messages getting marked as spam, consider taking more control of the email delivery yourself.
As a first step, consider using a custom domain with your project. Email that comes from a custom domain has less chance of being marked as span.
As a second step, consider setting up your own SMTP server.) for delivering the email, so that the emails are not being delivered from Firebase's shared infrastructure anymore.
While these steps are more involved, they typically will drastically reduce the cases where the messages from Firebase Authentication are marked as spam.
Full Guide Based on Frank's Answer
Firstly create a new email account you can use to relay the Firebase emails through the SMTP server with. I personally chose Gmail, but I tested with Outlook and it also works.
You can now find an SMTP server host that will work for your scenario. If you're sending less than 1000 emails per month you can find free and reliable hosts. I chose SMTP2GO's free option.
Now you've found the SMTP host, add the email address you've chosen as a single sender email (note that if you do own a domain, you can alternatively use that to send emails).
Note that you will have to verify the email, usually by your host sending a link to the email's inbox. Make sure to check spam.
Once verified, navigate to where you host allows you to add SMTP Users and add a new user. This will allocate an SMTP username and password.
Navigate to the Firebase console, and choose the Authentication option from the sidebar (within the Build product category).
Go to Templates → SMTP Settings and enter the details of your SMTP server. The username and password fields are to be filled with the SMTP user login you created in the step above.
It is better to use TLS, but I believe SSL should work too but it is untested.
Click save, and you're all set up - but there may still be steps to perform depending on your email provider.
Provider Specific Steps
If the emails are being sent to an account managed by Google you will have no issues with your emails being quarantined by anti-spam policies and it will work immediately.
If you are using Outlook, you will have a different problem on your hands. Outlook's built in defender will most likely have auto-quarantined your email under multiple policies - that bit is important.
These policies are likely to be both spam and phish policies. If you unblock one of them, the other will catch it and re-quarantine.
Unblock both policies for the email address, and test. You can see the status of quarantined messages in Microsoft 365 Defender app under Review → Quarantine. Please note that you will need to be an administrator to add global allow policies to your email accounts.
If this still doesn't work it is likely that your company has an additional external filter (as mine did), and you will have to add the IP's manually to the Tenant Allow/Block Lists spoofed senders tab.
Let's say I have access to an https weather API.
Let's say I query its health status on thursday 17/08/2017 23h30 and the API replies OK (simple OK http code).
As a client, I need to prove in the future that the service actually responded me this data.
I'm thinking to asking the API to add a crypto signature of the data sent + timestamp, in order to prove they actually responded OK at that specific time.
Is it overkill? Is there a more simple way of doing it?
A digital signature containing current date/time or even adding a time stamp issued by a third party time stamp authority is an appropriate way to ensure that the content was actually issued on a date
In general, implementing a digital signature system on HTTP requests is not so simple and you have to consider many elements:
What content will you sign: headers, payload, attachments?
Is it binary content or text? Because the algorithms and signature formats will be different
In case of text you must canonicalize the content to avoid encoding problems when you verify the signature on the client side. Also you need to define a signature algorithm to compute the content to sign
Do you also need to sign the attachments when they are sent via streams?. How are you going to handle big files?
How are you going to attach the signature to the https response: special header, additional attribute in the payload?
How is the server going to distribute the signing certificate? You should include it in a truststore on the client
But, if you only want to proof that a service response was OK/FAIL, then the server just need to add a digital signature over the payload (or computed on a concatenation of the headers) but if you want to implement something more complex I suggest you take a look at the Json Web Signature (JWS)
I'm trying to develop a REST API web service. I have a question about how to handle user activation email. Currently, the API service handles email sending.
Here is the flow I have at the moment:
User registers via the client application
Client application POSTs to API service
API service validates and adds the user to the database
API service sends the User an activation link
User clicks on the activation link, which will take them to the client application activation page
Client application activation page POSTs to API service
Done
Here is where I currently see the issue:
Because the API service is currently sending the email, the client application does not have control over the look and feel of the email. And there may be URLs in the email that should point to the client application.
Another option is instead of the API service sending the activation email, it will return the activation key to the client application. The client application will then be able to send the activation email to the user.
Two issues I see with this strategy:
Security, as the activation key is now exposed to the client application.
Not DRY, as each client could be responsible for email sending.
What do you think is best way to handle this?
I would like to allow the client application to customize their email, as well as include client-specific URLs (activation page).
TL;DR
Create a small service for developers to create templates, let them declare which template they want to use when POSTing to your activation API
Summary of the problem:
e-mail needs to look different for every client app
sending mail should be implemented once
solution should be secure
There is no need for the e-mail to look different every time. So there's no need to send the e-mail format with the POST request.
Instead one of the following can be done:
1 Create a separate API endpoint to define templates and let the client app choose one of them when POSTing the request for activation.
This is not exactly secure, at least poses a challenge to make it safe if you want to accept HTML from the client apps.
Recommended solution:
2 Create a tool for developers (in the same website where they get their API key) that accepts templates and aids creating them. Client app can choose one of them when POSTing the request for activation. Fragment of the request body being something like:
...
"template": "foobar-app",
"fields": {
"title": "Welcome to foobar app",
"username": "jim78"
}
...
No HTML in the fields allowed.
This lets you have pre-defined templates prepared by the developer that can be used by your e-mail sending service and no bug in client app can cause the e-mail to become unsafe. Also, you get a place where the templates can be worked on and tested. (the developer can send them to himself to debug - making e-mail templates is horrible, belive me)
You'll be able to support your developers/clients better in the future and prepare a set of working templates tested in multiple mail clients.
A point about security and trust. Typically you send an activation email that contains a url link that has the activation code. The purpose of the email is to validate that the email is valid and that the user has access to that email. The only way the user could have received the verification link is through the email.
If you pass back the activation link to the client then anyone who has access to your API has access to the activation code. If they have access to the link they can bypass the verification process. This is really easy if you have a web app, as they just need to drop into the browser developer mode to see the link. If you have a fat client then they could snoop the network if you are not using encryption like https. They could also, if they were dedicated, decompile your binary (this is why you d not store keys in your binaries).
A backend should never trust a client to implement a security procedure because it never knows when it has been compromised. The safe and correct way is to do the activation email on the server side.
Another way to look at this, is that it is similar to the client saying "yes the user is authenticated so give me all the data"
As for the templates there are plenty of good answers above. I would suggest having a catalog of templates and a list of arguments that can be replaced.
So the way I achieved this in my opinion is quite a nice way. So I took the methodology of how JSON Web tokens work and applied it to my activation links. I'll explain how it works:
I have 2 web servers, one which handles the REST API, and one which handles the spa.
So the user registers, and the request is sent to the API. The response is then returned to the SPA at which point if successful sends a request to the SPA Backend which signs a token with the user's credentials, the purpose of the token (which is this case is to verify the email address) and it's expiry date.
This token is sent to the user's email address, however on the REST server there is a receiving route that will decode the token and if valid, verifies the email address.
This does mean that technically only 1st party clients can authenticate the email address as they are the only ones that can know your cipher secret. If your secret was freely handed out, then the problem would occur that anyone could verify their email address.
I hope this helps!
EDIT: another way would be to pass a template built in handlebars or something that swaps out variables for actual values. Then have the REST api render it, and email it. (This is probably the best way imo haha)
Your API could have an IEmailBodyFormatter object that is passed as a parameter to your API call....
I'd extend step 2 with additional post-data sent to the server:
"mail":{
"placeholder":"someStringChoosenByClientWhichWillBeReplaceByActivationCode",
"subject":"Hey there, please activate",
"ishtml":false,
"body":"SSdtIHRyeWluZyB0byBkZXZlbG9wIGEgUkVTVCBBUEkgd2ViIHNlcnZpY2UuIEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IGhvdyB0byBoYW5kbGUgdXNlciBhY3RpdmF0aW9uIGVtYWlsLiBDdXJyZW50bHksIHRoZSBBUEkgc2VydmljZSBoYW5kbGVzIGVtYWlsIHNlbmRpbmcu"
"attachments":[
{
"content-type":"image/png",
"filename":"inline_logo.png",
"content":"base64_data_of_image"
}
]
}
This would allow the client full control over sent message, but the activation procedure (mail generation & delivery) is still handled by the service.
Everything except the activation key can be generated for every user by the client (e.g. using "Hello XYZ" as Subject).
I'm not sure whether it's an good idea to allow html-Mails ("ishtml":false,), this depends on your application and the amount of time you want to spent implementing this.
Allow the client to manage their own email template(s). When they post a new user registration, allow them to specify which template to use. Then your application is sending the email message, but clients can control what it looks like.
POST /email-templates
{
"subject": "Complete Your Registration",
"body": "<html>Follow this link to complete your registration: {activationLink}. It is valid for 45 minutes.</html>"
}
POST /registration-requests
{
"name": "John Q. Public",
"emailTemplate": "/email-templates/45"
}
I think the proper way is to expose the activation key for the client to do whatever it wants with.
You could also add another endpoint to send the activation key for the user.
Returns user. (with the url like User/{userid} and other resources url like User/{userid}/ActivationKey)
User (POST)
This can returns the current user and other resources like Email, Activate, etc.
For info about the key (like dates, expiration, etc)
User/{userid}/ActivationKey
from there you can extend it as long as you want with :
Preview activation email:
User/{userid}/ActivationKey/Email (GET)
Update activation email with template, smtp server, etc of the email. :
User/{userid}/ActivationKey/Email (PUT)
Create (and send) activation email, possible with date to send or other send options (text-html versions, etc) :
User/{userid}/ActivationKey/Email (POST)
You could possibly list all email sent and preview them in another endpoint if necessary.
User/{userid}/Emails (GET)
User/{userid}/Emails/{emailid} (GET)
I join nauktur on the idea of letting the client send you a template of his email. (And +1 for talking about a way to test, because I agree on the awfulness of mail "development").
But why so complicated ? Client apps mean developers, so why not let them give them your default template (with HTML), let them play around if they want to, and send you back the version they prefer ?
It's not a lot of work for you (just a new field in the client table and a new route), and it gives them a lot of options.
Here is a basic example where we'll be exposing some parameters so that they can play around with the HTML without even having to know them :
app.name
app.description
activation_code
user.* registering info
Basic template
{
title: "Your activation code for %{app.name}",
body: "<p>Hi, you've been registered on %{app.name}.
<p>%{app.description}</p>
<p>Follow this link to confirm your inscription."
}
Register new template
Then the client says : "I prefer to have a more simple mail, but I want his name in it !".
[PUT] /api/email/templates/client_id
{
title: "Your activation code",
body: "<p>Hi %{user.fullname}, Follow this link to confirm your inscription."
}
And here you go. Let them play with HTML, it allows way more personalization.
There's no harm in it except for their image on their clients if they mess up, but they're their clients.
Security issues
It was pointed out that attackers could get access to the token of the client app could inject malicious content in the template. First of all, the risk is already so high if the token leaks, that this is the last of your concerns. Still, if you're scared of this, disallowing img tags and making the content of a tags match the href attribute should solve your issue.
I have a vb.net application that uses my gmail smtp server settings and my password to send me the users feedback through the email, (I don't want to show my email to the users)
The problem is I want to store these data securely in the vb.net application so that It's hard for any hackers/crackers through (reverse engineering or programs like cheat engine) to get my gmail account data.
Any ideas are welcome.
You cannot be 100% secure, you could store the email in a resource file and use an obsficator to make it much harder to get at the string but it is possible to break it (encrypted resource files and strings). However Even if you used a different email address and setup a forwarding rule the password for that account could still be comprimised. Anything you have access to in code a hacker could potentially break into as the key will be in clear text at some point.
You have a number of secure options:
Setup a webservice to receive your messages and email them onto you/log them to a database
Log your messages to a 3rd Party system (irc? news? some p2p network, IM system), and pick um the messages later.
Setup a Source Control/issue site for your system, google code/bitbucket/something else that has the ability to receive issues via an api.
I don't know if this makes any sense but what I'd do is let the program run an external PHP script that sends the mail.
Basically, if I'm understanding your question, you don't want the password in clear text in your .exe. Correct?
The solution is simply to ENCRYPT the string in your program, then decrypt it at runtime (pass your decrypted variable to your e-mail function).
Any two-way encryption will work. For example:
http://www.vbdotnetforums.com/security/1240-encrypt-password.html
As other people pointed out saving the password to your email in your application is unsafe because somebody might be able to crack your code and retrieve your password.
For logging errors, I suggest creating a very small PHP script and putting it on a PHP server. When an error occurs in your VB.NET application, the application can send data to this .php script. The script can save the data in a file or in a MySQL database.
All the things you need for sending data to PHP scripts can be found in "System. Net. WebRequest" namespace in VB.NET.
If you cannot use a PHP script, you may use a combination of IsolatedStorage ("System.IO.IsolatedStorage" namespace) and Cryptography ("System.Security.Cryptography" namespace) to save sensitive data. But, this is not completely secure to savvy attackers.
Currently on our system, when a user contacts us, we reply via our admin panel. The user is then sent an email containing our message and the other messages in the conversation.
Then the user has to click on 'Reply to this message' which opens up our website, with a contact enquiry form, and submits the message to the conversation (using a QueryString to tell which conversation it belongs to).
However, a lot of users like to simply reply to the email sent to them.
How can I track their reply and automatically add this to the same conversation?
We're currently using ASP.NET 3.5, IIS6 & SQL Server 2005, however will be upgrading to ASP.NET 4.0, IIS7 & SQL Server 2008
Thanks,
Curt
It's not a full code solution (but hey, that's not what this place is for anyway), but this is a general idea:
Specify a reply-to header in the messages you send (or simply use the from address). Then set up a script that periodically reads the emails send to that address and inserts them into your database (to be viewed). In order to get the correct threads, you can use the in-reply-to header in the message sent to you. I don't know by heart how to find the message-id of a mail you sent, but a little research on your part should reveal that. (if worst comes to worst, you can always BCC yourself the message and read it from there, but there should be easier ways).
Note that some people (most notably GMail) refuse to use in-reply-to headers because of how people use email (though I don't think it would be much of a problem in the case you are describing) and use topics to create threads instead. This may be an easier solution, though it may be less reliable in your case.