This project is read-only.

FBA and Users without E-Mail

Topics: Internet/Extranet Edition
Sep 30, 2008 at 3:36 PM

I'm thinking about ways to enable an intranet to be accessed by workers in a factory in China who don't have e-mail (actually, I'm not even quite sure if they can read - I'm not sure how high illiteracy is among factory workers there). My customer has different locations around the world and wants to set up intRAnet stations for the workers who don't have their own PCs (and also no Active Directory accounts and no e-mail).

A simple way would of course be just to set a global login or leave everything open for anonymous users.

Using FBA maybe there would be a simple way to:
- unrequire e-mail address when requesting membership
- automatically approve the user
- redirect new user to a page where he can set his password
(someway like the change password page, except he doesn't know his temporary password)

Any ideas on this - or better ideas?

Sep 30, 2008 at 6:24 PM
I guess this would be possible.  During the process of creating a request, everything is assembled in one request object, and then the user is created, and then the email goes out.  It would be fairly easy to simply display the information that would go into the email, rather than call SendMail.

I've thought about adding the ability for the user to enter their own password.  The whole point of the temporary password is to validate their email address, but there are cases you might not care whether they have one or not (typical for a blog comment). 

You could do it with a redirect to the change password page, but it seems to me it would be better to put the enter and confirm password fields in the create user wizard in the first place.

You'd have to account for the case where a user forgets their password, and use the password question/answer to validate their identity before displaying the password or allowing them to choose a new one.

It sounds like a fair number of modifications, but in your case, without a backend system to validate the user's identity, it's hard to see where this authentication would be necessary.  If you're using it to remember a particular user for some reason, there's no way to prevent a user from creating a new account every time they visit.  If you just want to remember them for a particular session, it seems like a session cookie would nearly be enough to do any user tracking you'd need.

Mike Sharp