i'm doing with silverlight 4 for consultation booking system. what i wondering is, in my application required multiple kind of user register and login. admin having different format of admin ID, lecturer having different format of lecturer ID. i'm trying to implement with silverlight for role and authentication merchant. i think might because of silverlight membership can be done easily with asp.netmembershipprover, i could not find any resource to edit the default form for it or custom made the membership merchant for my application. may i know is there any article or resource you know on how to implement this, or any idea you can suggest to me ?? Thank you
Resources i found:
http://www.silverlight.net/learn/graphics/file-and-local-data/isolated-storage-(silverlight-quickstart)
i thinking of using the isolated storage to store the user logged in boolean but sound like not so secure
http://msdn.microsoft.com/en-us/library/ee942451(v=vs.91).aspx
the resources mention of using the default asp.net membership but no comment on how to edit the default set.
You can use default MembershipProvider to manage general user information such as username, password, security question, login etc. Then you create additional table to store your own information, of course you need to create Page to manage these data by yourself.
Table: aspnet_users
UserId
UserName
...
Table: YourCustomData
UserId
AdminId
AdminText
...
Related
We are removing User, User Group and Permission models from our backend in favor of Auth0.
Our first idea was to just delete User, Group and Permission tables from DB and replace related foreign keys with varchar field. In this field we would then enter IDs that we get from Auth0 in JWT (pointing to something not present in our DB).
Is this good approach? I somehow feel that there must be more "relational" way of doing this.
Generally OAuth will not do all of the permission checks for you. Instead it gives you general mechanisms to sign the user in and issue + validate tokens.
In most real world architectures you also need to manage a second level of authorization in your back end - using domain specific user data for roles, permissions etc.
A couple of write ups of mine may help:
User Data Management
API Authorization
Auth0 Community Manager Dan here,
In this scenario you may be able to leverage the RBAC to replace your existing users/groups/permissions setup.
You would register a user's roles and the associated permissions of each role in the Auth0 dashboard or programmatically via the management API. Then you can setup a rule to add user roles to the token.
To connect this user to your existing user data store you can store the Auth0 id, similarly to how you have described.
This allows you to lookup the user when the token is received, and to associate any permissions or roles the user has. You can make roles API-specific by adding a prefix to the role, or have roles be general depending on your needs.
I've got a small review system built in AngularJS and Firebase and the only way to identify which review is made by which user is via the uid of the user. The idea is when you then click on the user's name, you should be taken to the profile of that user.
So I would then create a route looking like /profile/{{review.author.uid}} which could translate into /profile/facebook:123234243 for example.
My question is, does it pose a security threat showing the uid in the url like this? Can it be used for any malicious actions against a user's third party account etc?
I've tried looking through their website but I can't find anything on this subject.
EDIT: Note that I need a Firebase specific answer, not a generic one about database id:s.
2 quick question:
is it possible to build a Facebook application saving user profile informations (name, surname, phone numners, ecc.) on a external custom database (so, not FB database), obvioulsy after user approval, etc.
even if the answer of the above question is "no", do you know a way to pull out user profile information for all users who use the FB application and formally agree to give their personal information within the app? I would like to know if it is possible to do that both from a technical pov and legal pov
That´s what a privacy policy is for. In general, you should only store data after telling the user exactly what you store, what you do with the data, how long you store it and how he can get his entries deleted from your database.
Btw, you can´t get the phone number. About the technical way, please go to the Facebook docs: https://developers.facebook.com/docs
As we all know that we may extend the profile information based on ASP.NET Identity to another table or include it to the default table (ASPNetUsers).
Supposingly i only have two field to be fill in during registration (username and email) only, but upon completing registration, user may or may not opt to fill in extra profile information (such as sex, birthdate, real name etc).
I have two options in my mind but not sure which is the more appropriate way.
All profile information (username, email, sex, birthdate, real name) include in the default identity ASPNetUsers table.
Required registration information(username and email) for default identity ASPNetUsers table, while the extra profile information is in another table which is linked to the default identity ASPNetUsers table.
Or is there any better option? Hope that we may gain something new in this discussion.
I would go with option 2. As the profile is likely to change. More over if I need to take out the identity to some other server it is easy to take them there. or later to extend to federated identity(well.. this can act both ways due to sync issues).
You'll need to add custom properties as a Claim on user. Then in your views access these claims from ClaimsPrincipal.Current.Claims.
Claims on principal are available in the cookie, so no extra DB hits required.
I think this is the best and most performant solution
How to user claims in asp.net identity
I'm working on a project where there are several solutions using the same Authentication/Authorization project.
The authentication project is the only one that uses tables AspNetUsers, AspNetRoles, ...
By the other hand, other projects have their own "Users" table with the extra information that each one need.
If one project need "BirthDate" and other project needs "Sex", we are not going to put both in the common
authentication tables, giving to all projects extra information that isn't useful for each one.
Working that way we are also giving the "Single responsability" of Authentication and Authorization to
one project, avoiding the code repeating.
That's why I think that the second option is more scalable and maintainable.
I have few tables like example.
Users Books UsersBookPurchase
UID BookId UserId
UName Name BookId
Password Price
Email
This is fine. I am having my own login system but i am also using some 3rd party to validate like OpenID or facebook Authetication. My question is if the user is able to log in successfully using OpenID or facebook Authentication, what steps do i need to do i.e do i have to insert one fake row in Users table because if i do not insert how will integrity be maintained. I mean what user id should i insert in UsersBookPurchase when the person who has logged in using Facebook Authentication has made a purchase because the UserId is reference key from Users table. Please give me a high level overview of what i need to do because this is fairly common scenario.
Thanks in advance :)
Basically yes. Don't think of it as a fake row. What you should do is to create an actual user account based on the data provided by Facebook API (I am not that familiar with OpenID)
Facebook API will provide you with first and last name, email address, maybe some other data
Facebook does not have the concept of login name, users login by email address.
What you do is just create a new user from the data provided by API.
There are some things to watchout for: it is possible that user is already registered on your site. When you get data from Facebook you should search your own user table to see if the email address already belongs to your own registered user and it that case you can do some fancy things like mark that user as also having a facebook login.
If I were to do that, I'd abstracted login info into a separate table and have some sort of type in the User table. The type is used to identify what auth method is used, i.e. your own, Google, etc. If a user does select using alternative methods, you do need to have association but with a different type. But yes it is a new record.