Start a new topic

Change or implement new way of sharing to external users

 Hi,


Currently, if user does external share, temp user name and password is generated and sent in plain text, also it is known to person who shares. This is not secure.


I would like to request new feature for external shares:

When internal or LDAP user shares externally, I suggest that unique invite to register links would be generated for each recipient, where they could register themselves (by creating user name and password). Each link should be unique for each recipient (maybe inserted via variable in email template). Reason being, we want that only recipient knew his password and no one else.


It should be possible to set optional expiration for such self registered accounts by user who shares (similar to what is implemented with current external shares).

Current workaround with creating "register" user and a webform, isn't working well for these reasons:
* Link is always the same, and can be leaked
* User created are internal, instead of external
* Admin must enable self registered accounts
* No optional expiration
1 Comment

Karolis,


Self registered users can have automatic expirations applied to them, and can be auto enabled if you so choose.  Its just a little more custom CrushTask to allow for that.


What your asking for though is replicating what we already suggest doing with register and custom tasks...so its not something we will be adding like that.


The link being sent to a user is not a multiple use thing.  They will use it one time.  Its not a user/pass.  Its a "token" and should be thought of like that.  The fact that we split the token into two parts and put one part into user field and the part into pass field is irrelevant, its just a convention we are using.  You can make the token be 16 characters long if you like, or even 50 long, and so on.  Then people won't look at it and think that its their "username" since its so long it can't be remembered.


The same sort of tokenized download system is used everywhere for servers and secure files, or temporary access.


This is not an account for the user...the user may have 20 tokens from prior shares and stuff, they don't have one common token they use again and again for their field they have been granted.


Thanks,

Ben

Login to post a comment