I am using ASP.NET identity in MVC 5 and wondered the best way to perform string comparison during say, a query to a table where records have been entered with the userId as an foreign key.
Normally I would just plump for == but I wasn't sure how the string for a userId inside .NET identity is created.
I guess it's actually a GUID of sorts under the hood so I'd presume that == would be fine but I wondered if the culture or case would come into it at all.
Does anyone know if the string is a unique GUID for == type comparison, or should I be using string.Equals and some StringComparison option to account for cultures?
ASP.NET Identity can use GUID for keys. In that case GUID should not have any culture specific characters. So StringComparision. InvariantCultureIgnoreCase should go for string.Equals in C#. ToLower (ToUpper) can be used for SQL queries (LINQ).
You probably want to use Ordinal/OrdinalIgnoreCase StringComparisons here as it compares strings character by character without regard to linguistic convention.
Read more here: https://msdn.microsoft.com/en-us/library/cc165449.aspx
And here: https://msdn.microsoft.com/en-us/library/system.stringcomparison(v=vs.110).aspx
Code samples:
string1.Equals(string2, StringComparison.Ordinal);
string1.Equals(string2, StringComparison.OrdinalIgnoreCase);
Related
I'm trying to understand why the new ASP.NET Identity tables stopped using Guid (uniqueidentifier type) as keys - instead it is now using nvarchar(128) but still keep a Guid as a string...
Isn't it a huge waste? (uniqueidentifier is just 2 integers vs the whole Guid as a 36 character string)
I'm suspecting that Entity Framework might be responsible for this...
Is it safe to change back to uniqueidentifier keys?
Can anyone tell me what are the benefits of using 36 character strings?
Identity is built to work on multiple storage platforms and not every storage platform has Guid as a supported storage type.
You can change the default string pkey into Guid, but that involves some work on your C# models. Or you can change the pkey into an int - whatever you like. Just be aware that there is a huge debate about which is better.
Microsoft.AspNet.Identity.EntityFramework -
Objects UserIdentity and RoleIdenity have Id fields of type string, and thus the tables created have data types nvarchar(128).
Shouldn't these objects Id properties be of type System.Guid and the database have datatypes of uniqueidentifier? Why aren't they? A GUID is inserted on new User and Role creation.
It's most likely because the api is storage provider independent so the kept the field types as generic as possible: http://blogs.msdn.com/b/webdev/archive/2013/06/27/introducing-asp-net-identity-membership-system-for-asp-net-applications.aspx
"If your application requirements are that this information might be stored in a different storage mechanism such as SharePoint, Azure Table Service, No Sql databases etc. it is now possible to plug in different storage providers."
Hao Kung from the ASP.NET team wrote this in a comment on this question on how to change id type to int.
So we decided on string keys to avoid having to deal with key serialization issues, the EF default implementation could have used ints as the primary key, GUIDs were just an easy way to generate a random unique string key.
Another reason for a string user ID may be that strings are hard coded into the claims API, specifically, Microsoft.AspNet.Identity.IdentityExtensions.GetUserId, which uses System.Security.Claims.Value, both of which return strings.
I have a huge query string which is around 6000 to 7000 characters, is it possible to encrpyt the string in short?
any alogrithms ?
Usign ASP.NET as the web app.
The short answer is don't do it - it probably indicates you are doing something wrong.
If you have to then I would say the best way would be to store the long query string in a database field and generate a Guid you can store as a key against it.
You can then pass the Guid in the query string and when the page loads you can then retrieve the full details from the database using the key.
The URL accepts 255 character, after that you'll get nothing.
Use what Mr. Kevin mentioned, database storage, or use the context session to store variables you are sending in the query string.
I'm wondering if it's possible for me to get the QuestionAnswer field from ASP.NET membership in the same way that you can get the UserName and PasswordQuestion.
MembershipUser mu = Membership.GetUser(userId);
string username = mu.UserName;
string question = mu.PasswordQuestion;
I'm pretty certain that the QuestionAnswer is hashed in the database in the same way that the password is. If that is the case then you won't be able to get the QuestionAnswer in any sort of human-readable format (although if you require the QuestionAnswer in this format you can always run a regular SQL query against the table rather than using the Membership API).
If needed you can always change the password question and answer
Hope this helps.
I need to compare the answer in with the aspnet_membership tables PasswordAnswer value.
The text in Password answer is in the form of Hashed. What algorithm they have used how they implemented the Salt value in ASP.net Membership Provider.
I have tried hashing (sh1) and compared with text what is salt value
How to hash my answer value.
string answer = "one";
string hashedvalue = "dfdsfsdfdsfdsfdfdf";
I need to compare this both.
I have converted the answer to hashed format. But both are different> I think due to salt value. How can I utilize this.
You should be using the Membership class' ValidateUser method to do this.