Preconfigured Username
Slind14 opened this issue · comments
Hi there,
it would be great if the username could be predefined using a get param on the embed link.
In my use case I would need a secure way for this, therefor it would be awesome if this could also be done with encryption. E.g. this is how intercom does it: https://docs.intercom.com/configure-intercom-for-your-product-or-site/staying-secure/enable-identity-verification-on-your-web-product
@acobeppp No worries, I take github issues. (Otherwise it would've been disabled by now)
@Slind14 I will be looking at how intercom implements it. At this moment, we do have the username query parameter that you can pass into and have it prefill the field. https://github.com/TitanEmbeds/Titan/blob/master/webapp/titanembeds/constants.py#L70
Once the site will be redone in a few months (so that we will support different server sessions, not same login under whole site), I'll implement heavier features for embed creators.
^
Its not secure, everyone can specify every username.
Why would that matter? Even if it would be ‘secure’ you’d still be able to change it.
This would need to be lockable, too.
Because I wand to force everyone to use their community name and people able to trust that it is really the this person.
This doesn't verify their name with their website name either
I want to use it as a community chat ;)
Is your site using Wordpress, perhaps?
No, its using woltlab.
Hmm... looks proprietary... :-/ If it was Wordpress it maybe would’ve been possible for some kind of plug-in...
I would write the integration my self.
I would just need Titan to support said behavior e.g. https://docs.intercom.com/configure-intercom-for-your-product-or-site/staying-secure/enable-identity-verification-on-your-web-product
As I stated in my original comment, I will rewrite the whole TItan Embeds so that it is efficient and a better looking frontend. During the rewrite, I will change the sessions so that they are per-widget, not for the whole site. That way, each individual embeds would have it's own login and have stuff like custom usernames that the webmaster can set.
Here is what I'm thinking about the implementation. For the server side, I'm thinking of having the browser communicating with the client (your) website and grab the "token" which can be used to login to the embed. During that process, your website backend would communicate with our server with a given username and we'll assign that one-use token. The token would set the user as the given username provided by the server.
I'm speaking at an abstract sense at this moment (as I haven't figured out the internals as of yet). However, I'm all ears for feedback before I go ahead and implement the features during the rewrite. Do you think the steps above would work?
That would be great, though I would like to suggest an even simpler method.
The most simple but still secure solution is like intercom is doing it. It narrows down to encrypting the user name (+ some verification string) with a salt that is known only by the users server and TitanEmbeds.
This way, there does not need to be any communication between TitanEmbeds and the Website, since the encrypted string is provided with the embed code and TitanEmbeds decrypts it based on the secret salt.
- Setup TitanEmbeds Account
- User enables Forced Secure Login
- TitanEmbeds provides a salt/key for hmac
- TitanEmbeds provides the widget code with a placeholder for the hmac
- The users integrates TitanEmbeds and programmatically replace the placeholder with a generated hmac based on the provided salt/key.
- The user visits the page, the widget is loaded with the hmac set and starts the authentication:
- TitanEmbeds tries to decrypt the hmac based on the salt/key it provided, if it works, it uses the decrypted hmac as username and signs him in.
This has the major advantage that hmac is intended for authentication and is available in most languages. It is super easy to integrate for the user and for you in TitanEmbeds, too.
https://security.stackexchange.com/questions/20129/how-and-when-do-i-use-hmac/20301
What do you think?
Ooh interesting. Since the HMAC is visible to the user via inspect element (possibly by the website scripts), won't the user be able to make the API calls behalf of the website and set his/her username with the given HMAC? Originally I was thinking of having the user's server store the secrets and able to make the calls.
Yes, the user him self would be able to do that. But no one else would be able to and the user would only be able to do this with his own account. So it is not really a security risk unless you have some nasty (non iframed/sandboxed) javascript on your own website which reads this information but in this incident the website account login information and everything displayed wouldn't be secure either.
As I said before intercom is using this authentication. I don't know if you know their product, they have a lot of enterprise customers who are conducting private communication with their clients this way.
Ah alright. But didn't you say earlier that you want to pick the usernames for the user? So if the user themselves can pick the usernames, wouldn't it defeat the purpose that it is secure? And unfortunately no, I have never used any of the intercom products.
I want to pick the username for the user in terms of it being the same as their website account name.
The user can pick a custom username on the website (not TitanEmbeds).
This ensures that everyone is who it says he is. (No masquerade / pretending to be someone else)
Does that make sense?
That makes sense. Thanks for clarifying!
Any update on this future update?