Suppose you have two endpoints in a mule application and you want to restrict access of one endpoint to a particular client application and make only another endpoint available for access.How can you implement this?
You can use a custom policy to achieve the same. So far, there is no OOTB policy available for the same. The other thing you could do but is not as elegant a solution ( this is also applicable in case you are not using API manager aspect of the platform) is making use of filter in the Mule application (Mule3) and validation module in Mule4 whereby if the incoming request (for a given resource/HTTP verb combination) has a particular clientId you drop/filter that request while you let others go through..
We are integrating FusionAuth into our user account / profile system for 3 SaaS apps. We'll have about 5 roles established and the onboarding process for each such user is different.
A new user signup could be brand new, could be existing but for a new role, or could be reactivation of an account. So roughly speaking we might need to establish 3 x 5 x 2 (new and returning user) emails for account verification and then the same number of welcome emails. Each email will have specific instructional text, email subject, and links.
The ability to duplicate email templates in the FusionAuth UI would be useful but clearly this isn't a complete solution. If I create multiple tenants to support our development, testing and production releases - it would really be great to be able to maintain a master list of versioned templates and to link any one of those email template versions to any tenant and app.
If you are familiar with SendGrid - the versioned templates there are pretty nice, as is the conditional logic that can be used in the templates to reduce the total number of documents that must be maintained.
For my sanity and for the maintenance burden associated with these emails, I'd like to use only FusionAuth or only SendGrid for these account maintenance emails. Since SendGrid is the more robust email solution it might be the better choice.
What can be accomplished with FusionAuth's User Actions? Can all FusionAuth email templates can be disabled from the FusionAuthUI and API?
Adding a user from our UI will require creating (or returning) the FusionAuth user, setting the FusionAuth App registration, setting the role, then triggering the necessary email.
It could be really cool if all that can be configured as a multistep User Action that creates / updates and configures the user and then triggers the SendGrid template email.
The versioning and duplicate options for email templates are great ideas. FusionAuth does not currently support email template versioning or copy / duplicate in the UI. Can you open these as feature requests in GitHub? https://github.com/FusionAuth/fusionauth-issues/issues
We do support conditional logic within the template. There is a brief tutorial in the FusionAuth docs. https://fusionauth.io/docs/v1/tech/email-templates/email-templates
To build conditional logic you can use essentially anything that FreeMarker supports. https://freemarker.apache.org/
For example
[#if user.data.favoriteColor == "blue"]
Hi ${user.firstName}, I see you like the color blue.
[#else]
Hi ${user.firstName},
[/#if]
If you have some particular use cases or need some help building the logic in your template feel free to ask for help in the FusionAuth Slack channel or ask here.
That said - SendGrid is in the email game, they will likely have some powerful features not available in FusionAuth. If you require many power user features, I wouldn't try to dissuade you from using SendGrid. But do open feature requests so we can make our email templates as useful as possible.
What can be accomplished with FusionAuth's User Actions?
User actions are sort of free form events that will be sent using our Webhook configuration. They can only be taken on a user that already exists in FusionAuth, so it may not be the right fit for your use case. In addition to User Actions, you can enable events such as user.create, etc - so you can respond to these types of events in FusionAuth if that is helpful.
Can all FusionAuth email templates can be disabled from the FusionAuthUI and API?
Not sure what you mean - you can disable the SMTP email configuration which implicitly disables all use of email. This can be done via the System Configuration API. https://fusionauth.io/docs/v1/tech/apis/system#update-the-system-configuration See systemConfiguration.emailConfiguration.enabled. FusionAuth is an API first, so everything you can do in the API you can do through an API.
It could be really cool if all that can be configured as a multistep User Action that creates / updates and configures the user and then triggers the SendGrid template email.
User Actions will not help with this use case. However, you may be able to accomplish this in fewer API calls. If you know the user does not yet exist, you can use the Combo API (Create User + Registration) to create and register the user in one step. https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-and-registration-combined
If you omit the roles from this request, the user will be assigned any default roles configured on the application.
If you enable Registration Verification, this will send the user an email of your choosing. This is primarily intended to verify the user intended to register for the application.
The custom workflow idea is a good one however, feel free to open an issue on GitHub. I would envision it as a work flow builder for an application.
Example:
On user registration:
1. Assign role(s): [x] user
[ ] manager
[ ] admin
2. Send email: [select box for email template]
When using attribute routing, is it possible to remove routes based on certain runtime condition - such as licensing?
Something like this:
[LicensedRoute("/api/whatever")]
where '/api/whatever' is only added to the route table if the application is licensed.
Obviously I can explicitly do the check in the action method or use an action filter to validate the requests but ultimately I prefer the route not to be available if the software is not licensed.
Seems you need Attribute Routing: http://www.asp.net/web-api/overview/web-api-routing-and-actions/attribute-routing-in-web-api-2
Is it RESTful? How you store the licensing info: is it user logins? tokens? key?
You could do it RESTful and force the client to pass a token every time via token-based authentication, for example: define several "licence" levels/types (eg. Free/Trial/Basic/Pro) and then in a persistent storage (table) map tokens (guids) to a licence type.
Then using a custom attribute, mark each endpoint/controller/action with the minimum required licence type to be accessible (e.g. [MinimumLicence("Basic")]). And then create "routing tables" based on the licence required.
In this case you would deny access to routes rather than "remove" them.
is there any way by which we change the presence of other contacts using ApplicationEndPoint, one way which i came across was to create a UserEndpoint and then make presence related changes, but that required credentials to establish UserEndPoint.
Presence is aggregated value, even if you publish extra UserEndPoint it would affect only aggregated value taking in consideration all over published UserEndPoint from the same user. Then what is the meaning of changes in presentity value?
You cannot publish presence from an Application Endpoint, you will need to create a UserEndpoint using the SIP uri of the Application Endpoint, and then publish presence using _userEndPoint.LocalOwnerPresence.BeginPublishPresence()
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.