Feature Request: Password generating logic.

[dardarlt]

Could password generating logic be implemented?

This should let site admins to implement 3rd party registration, identify users and so on.  For example if username is USER, somewhere in HFS options you just enter secret code SECRET_CODE and maybe some password generating logic like: md5(%user . %secret_code) and user automatically gets a password like md5(USER . SECRET_CODE)).

[TSG]

3rd party registrations are impossible at this time, it is in the to-do list.

I don't think this idea will help. Others might understand the idea better than me though.

[rejetto]

that idea for generating the password is good when you don't want to actually store the account password.
with the static account handling of HFS, a random generator would be enough, even more secure, since it is more random than that.

at the moment, self creating accounts would be useless. there's no feature that would make profit of it (it takes some thinking to realize this).

[dardarlt]

This feature is not useless, and I'm already making some profit from it: 
I host some files using HFS, users can send SMS, after that they get account password and access to the content.

The main disadvantage is, that all users are getting the same username and the same password.

It's also a big disadvantage for HFS - any user can post his username and password anythere and all other users will get access to your content.

[bacter]

I'am with Rejetto when he says that at the moment self generating accounts will be useless. That means not that it would be useless in cases like the exposed by dardarlt. But to implement some valid solution for general purpose, there must be some thinking before.

- File access, download and upload permissions are actually done on a per-user-basis. So adding a new account would not ensure any access to any account/password protected ressource.

- Consecuently, any remote account generation only makes sense, when the accounting system will be expanded with groups, so that at the moment of account generation there may be assigned to that new account by default (or depending on interest-option submitted by the solicitant) a group (like newbies, newvisitors) that already exists and for which are already defined the access-rights in the vfs.

I invite everybody to think and write about a versatile way to implement usergroups to make a good design that could be implemented by rejetto or some helping coder. (I exposed some idea in http://www.rejetto.com/forum/index.php?topic=3762.msg1028388#msg1028388 that needs to be explained better, I know!).

I will start a new topic withhin some days about changing user administration to groups (perhaps for build 152 or hfs 2.3), so the access rights could be defined for groups, and adding accounts would not imply to crowl through the file system everytime we add a new user.

[dardarlt]

I really accept opinion, that without "user groups" it's quite useless.

[rejetto]

Groups are useful,
but they are not the only way to get this feature working.
See, in "restrict access" there is a "all existing accounts".
It is not useful in this case, because future accounts are not currently existing.
But if i add an "Any account" option, that will just give access to any account, the problem would be solved.

[bacter]

The 'any account' option is only a very partial solution, but in some way it could substitute the 'all existing accounts', so you have not to add nothing in those folders where you want access for all registered users.

But here is a (not very clean) workaround for dardarlt's problem:

Create a folder where only anonimous users have access.
put in that folder some text files, each with a user-password combination, in such a way you have previously generated the users by hand
Make a difftemplate for that folder that will display only the first file that was never downloaded.
Put in your main page a direct link (named something like: get account and password here) to that folder, make them download the unique visible file. Once they login, they won't see anymore that link as they are registered users.
If in that way you create perhaps ten or twenty users, you could make the passwords expire, creating separate logfiles for the users. When you see that a user does not connect in some days, simply change password in the file and in useraccount.

If that may be useful for you, try it. If not, forget it.

[dardarlt]

I really don't know, how to this:

• Make a difftemplate for that folder that will display only the first file that was never downloaded
• you could make the passwords expire, creating separate logfiles for the users

Also I should create some accounts at first in HFS ?

[rejetto]

• Make a difftemplate for that folder that will display only the first file that was never downloaded

this is not possible at the moment

• you could make the passwords expire, creating separate logfiles for the users

accounts can already be managed by an external application, via command line.
if someone is interested in making such application...

[dardarlt]

But these account data are encoded... How do I decode it? Is there any info on this topic?

[bacter]

• Make a difftemplate for that folder that will display only the first file that was never downloaded

this is not possible at the moment

It could be possible in a difftemplate for that folder with javascript, modifing the files and depending sections:no display at all.
In the section file assign the %item-url% to a variable if %item-dl-count% is 0.
then use this itemurl as a link to download a file with information about username and key.

[rejetto]

But these account data are encoded... How do I decode it? Is there any info on this topic?

it is base64 encoded.
when you decode it with base64, you get a string USERNAME:PASSWORD
base64 is a standard, you find the functions to encode and decode in every language.
what's yours?