Membership.FindUsersByName

  • Thread starter Thread starter Jonathan Wood
  • Start date Start date
J

Jonathan Wood

Can anyone tell me why FindUsersByName() returns a collection? Isn't it
necessary that user names are unique (how else would passwords be
validated?)

And what is the best way to determine if a user name is already in use?
Preferrably, I could do this without raising an exception--I just want to
know whether or not they exist.

Thanks!
 
the function does a sql like and supports sql wildcards, so even though
names are unique, the find can return multiples.

this also means to avoid injection attacks, you should check for sql
wildcard characters in usernames and email addresses.


-- bruce (sqlwork.com)
 
You're looking at the wrong function. The FindUsersByName is not meant to
get a user. It's meant to find a number of users that are similar to the
username entered. The stored procedure behind this uses LIKE instead of =,
this means you could say bob% and get all usernames that begin with bob.

What you want, instead is the GetUser. Best way to see if a user exists is
to just try a call to GetUser and if it returns null, then there is no user.
If it returns a MembershipUser object that isn't null, then you have a user.
 
Mark,
You're looking at the wrong function. The FindUsersByName is not meant to
get a user. It's meant to find a number of users that are similar to the
username entered. The stored procedure behind this uses LIKE instead of =,
this means you could say bob% and get all usernames that begin with bob.
Click to expand...

I'm not trying to get a user, I'm trying to find the number of users with a
specific user name or, in my case, email.
What you want, instead is the GetUser. Best way to see if a user exists is
to just try a call to GetUser and if it returns null, then there is no
user. If it returns a MembershipUser object that isn't null, then you have
a user.
Click to expand...

Here's where I get lost. Scanning the docs, I couldn't see anything about
GetUser returning null. If it does, that's perfect. But instead the
mentality seems to be raise an exception any time things aren't the way a
particular method thinks they should be.

Is there a way I'd be able to tell GetUser can return null on my own? That
would be a great help.

Thanks.
 
The documentation should always state what exceptions are thrown. Usually
when doing things such as returning objects from a function, the resultant
object will be null instead of throwing an exception. I use null tests on
GetUser(string username) all the time. Makes it much easier during a login
procedure to first check if the user even exists before bothering to
validate their credentials.

You could also use FindUsersByName but just test to see if your resultant
memberhsipusercollection has a length greater than 0 and isn't null. If it
does, then you know the user already exists. I like the GetUser though since
it's only trying to match a single name the performance may be the smallest
tad better.
 
Mark,
The documentation should always state what exceptions are thrown. Usually
when doing things such as returning objects from a function, the resultant
object will be null instead of throwing an exception. I use null tests on
GetUser(string username) all the time. Makes it much easier during a login
procedure to first check if the user even exists before bothering to
validate their credentials.
Click to expand...

I agree that it would be good if GetUser() returns null instead of throwing
an error when the user does not exist. But all the docs say is GetUser
throws a NotSupportedException, but doesn't say a single thing about when it
might do so. I find the .NET docs irritatingly terse.
You could also use FindUsersByName but just test to see if your resultant
memberhsipusercollection has a length greater than 0 and isn't null. If it
does, then you know the user already exists. I like the GetUser though
since it's only trying to match a single name the performance may be the
smallest tad better.
Click to expand...

Unless it's returning more information. But, as long as FindUsersByName also
returns null and won't throw an exception, then that would work as well.

Thanks.
 
Back
Top