Building a new Mobile Web Platform for Mobile Users to purchase & download content on their handsets. In the past we've used a completely bespoke login mechanism but I'm investigating using a Custom Membership Provider for the next version of the Platform.
The thing is, we have some slightly odd "login" mechanism requirements, so I'm not 100% sure that a MembershipProvider is the best fit.
Just looking for some general feed back on the requirements below with a "Yes, Membership Provider is a good fit" or "No, you're banging a square peg in a round hole"
Requirements
User may be required to login with a "Mobile Number" (username) & "Pin" (password) This fits pretty well, as they've already signed up and confirmed with an SMS and it satisfies the
ValidateUser(string username, string password)
Method ImplementationUser may be required to login with only a "Mobile Number". In this case, we don't bother doing the identity verification on our side. It reduces the number of steps for the user and verification is done by the particular operator when we attempt to bill them. (The operators can validate that the mobile number entered, matches with the handset when it hits the operator payment site)... so even though users have a password, we'd need to bluff the membership provider in someway, and let them in with a blank password.
User doesn't need to login at all. In this case, we can transparently bounce the user to a special network operator webpage, and we'll get the Mobile Number in Headers when they're transparently bounced back to us. In this case, we'd need to programmatically take that number from the headers, perform the login on their behalf in the code behind (again without any pin/password) and the user would be magically auto logged in.
Requirement 2 & 3 are bit odd. We essentially have 3 different login mechanisms that the one membership provider would need to satisfy.
- User Entered Mobile & User Entered Pin
- User Entered Mobile Only (code behind I suppose to satisfy the pin requirement)
- Completely Transparent Login (code behind to do the entire login process)
Anyone got any comments/feed back on the above or have any advice on any bizarre membership provider implementation you've done in the past.