-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow customizable email subjects #230
Comments
A secure way to do this is definitely nice, but I'm wondering how we'd do that. I'm not sure what kind of bad things a malicious RP could do if we simply let the RP override this in its call to The least problematic way would be to do this in configuration on the broker side, but then customising the templates would require a private broker instance. I think this is already possible per-install by simply modifying the files in Would it be sufficient for your use case if we simply extended this to be per-origin? So that you can have multiple Or is a private broker not an option? Then we'd have to figure out some protocol the (public) broker can follow to discover strings/templates, and also somehow make sure it's tamper proof. |
Complete agree, and I should have been more clear in my description that this is the solution I'm looking for.
These lines would imply that's not the case. At least based on these lines, it looks like the subject will always include the display origin. I think the easiest solution would be to provide an configuration variable that completely overrides the subject. While something that could interpolate values would be nice, I think it might be too much unnecessary complexity (at least to start with). |
Currently, Portier emails use the following subject:
Generally, this is fine since
display_origin
typically matches the URL of the service the user is trying to sign into. However, this isn't always the case, especially if the app is using a subdomain for handling the authentication process. For example, instead of seeing a subject like this:my users would see this:
As a good first step, it would be nice to be able to provide a naive override for the email subject, one that doesn't contain any dynamic data.
The text was updated successfully, but these errors were encountered: