Read password from workgroup file?

[Guest]

I would like to auto-generate an email to each user telling them, among other
things, their userid and password for using the package I am distributing. I
have no problem creating the email, and I have no problem getting their
username, but what code can I use to read their password from the workgoup
file so I can include it?

 

[Rick Brandt]

I would like to auto-generate an email to each user telling them,
among other things, their userid and password for using the package I
am distributing. I have no problem creating the email, and I have no
problem getting their username, but what code can I use to read their
password from the workgoup file so I can include it?

Code that could read passwords would render those passwords pretty useless
don't you think?

Users should create their own passwords.

 

[Guest]

Right! So they create their own passwords in a .mdw file I send them. They
could log in the first time with a temporary password that gets generated for
them (and which I know at that instant because I created it) and then they
overylay that with their own password, and then they lose, delete, or overlay
their special .mdw file I have created for them and they can no longer get
into the app that will let them access all the data in my central database.
So they call me and say, can you send me a new .mdw file and I say sure.
Now, I can do this 2 ways... I can generate a new temporary password and send
them the new .mdw and end up with numerous apparently duplicate .mdw files
floating around in my user community, each with some different combination of
UserIDs and passwords, OR, I can read the password via code from the central
copy of the .mdw file because my short term memory will not allow me to
remember what their current temporary password is, and auto-generate an email
to them, saying go back in with this temporary password and once in, change
the password to suit you..

So, is there a programmatic method of reading a password from a .mdw file?

 

[Rick Brandt]

Right! So they create their own passwords in a .mdw file I send
them. They could log in the first time with a temporary password
that gets generated for them (and which I know at that instant
because I created it) and then they overylay that with their own
password, and then they lose, delete, or overlay their special .mdw
file I have created for them and they can no longer get into the app
that will let them access all the data in my central database. So
they call me and say, can you send me a new .mdw file and I say sure.
Now, I can do this 2 ways... I can generate a new temporary password
and send them the new .mdw and end up with numerous apparently
duplicate .mdw files floating around in my user community, each with
some different combination of UserIDs and passwords, OR, I can read
the password via code from the central copy of the .mdw file because
my short term memory will not allow me to remember what their current
temporary password is, and auto-generate an email to them, saying go
back in with this temporary password and once in, change the password
to suit you..

So, is there a programmatic method of reading a password from a .mdw
file?

No.

Don't all of your users link to a common workgroup file on the network? If
a user forgets their password all you should have to do is clear the
password and then have them create a new one. There is no need for a
temporary one.

 

[Guest]

Unfortunately, we do not have the luxury of any files on a central server.
We use Rep/Sync. Even when we eventually do get a central server sometime
later this year, I fear some sort of Rep/Sync will be necessary because there
are lots of times my users have to work in a disconnected mode (on laptops).
So in that case they each need their own .mdw.

Looks like the only way to handle this is, since, when I create the account
I also specify the password, I will have to store the password, encrypted, in
some table, probably hidden. Then, when necessary, I can access the hidden
table, decrypt the password, and send it in an email. OR, send it encrypted
in an email and provide them with a small decryptor app.

 

[Rob Oldfield]

...or phone them up and tell them?

Unfortunately, we do not have the luxury of any files on a central server.
We use Rep/Sync. Even when we eventually do get a central server sometime
later this year, I fear some sort of Rep/Sync will be necessary because there
are lots of times my users have to work in a disconnected mode (on laptops).
So in that case they each need their own .mdw.

Looks like the only way to handle this is, since, when I create the account
I also specify the password, I will have to store the password, encrypted, in
some table, probably hidden. Then, when necessary, I can access the hidden
table, decrypt the password, and send it in an email. OR, send it encrypted
in an email and provide them with a small decryptor app.