I currently work on a iOS app witch uses Parse.com as backend. I do have the model but I'm a bit concerned about the privacy of "my" users. Since I need the functionality for a user to search for other users to send them invitations, I need the user class to be public but I don't want the email address to be public.
From what I've learned from stackoverflow is that this is a request for years.
My first idea was to add another class with all the private data and just Point to this class. The private class would be ACL secured on object level but I would lose the functionality to reset the users password.
Has anyone found a solution to keep the reset function? Is this something for cloud code?
The User data is not public on Parse. You can't directly do queries for other users.
When you do need to query for user, you explicitly add useMasterKey to your query.
Related
I am writing a public rest api, that uses api tokens that are one per application that uses it. I want to give the ability for the client to create users of the application, but not restrict them with what a user should be.
So I have API_USERS that need a token to authenticate to do any requests to the api. Lets say its an api for messages. So the messages from one application will be identified by that token, but how can I let the application that is using the api to be able to create their own users so that the messages in the database, are first uniquely identified for the application and then uniquely identified for the different users of the application if the application has such needs.
My idea is that I can just add another field like MESSAGE_OWNER and let the user handle how to create unique token for his users and maybe use his own database for storing users. Would that be a good solution? Is there another way I am not seeing?
I don't see an easy way to grant permissions to another user. It seems to be quite convoluted at the moment, and I wonder if I'm missing something obvious.
Say I want to invite another user to share a Realm. First I would have to ask the other user for their identification, then I would create the permission object, and then finally I would give the other user the address of my realm.
It would be great if I could share some sort of permission token via text message and let the new user register themselves. I suppose I could do that if I created another "User" which represented the shared group, and merely share this abstract user's credentials. It feels a bit hacky that way, but it seems easier to do.
I was hoping the demo application of the shared drawing environment would hold a clue, but after looking at the source code, it turns out both devices are logged in as the same user.
Am I missing something? Given the demo Draw application, how would one user practically invite a second user to join in their shared drawing environment? It seems like there would have to be a whole set of convoluted permissions and url/identification sharing handshakes.
Thanks for asking the question! Today, you will need to create a shared Realm that all users would input their user IDs into and have access to. This way any user can look up an ID and share access to another Realm.
We realize the limitations and are working on offering a number of improvements. The first is pretty close to what you describe, called a PermissionOffer object where you can inform the Realm Object Server you want to grant access to another user for a given Realm(s). The server will then provide a token you can share via any means with the other user. That user can then use the token to create a PermissionOfferResponse object and accept the access grant. This is coming soon, so stay tuned!
Later, we plan to offer a way to lookup user IDs so you don't have to replicate all of them in a shared Realm (see this issue).
We are using identityserver3 and membership reboot for authentication in our application.
We now have a requirement to change the UserName Email and Reset Users Passwords form an Admin area in our application. I have seen Identity Manager but that seems to not be what I'm looking for. From reading Membership Reboot Wiki it seems to support everything that I would want to do. I just don't have a clue what the implementation for this would look like.
My thought is that we would call into our API where we know that the user is authenticated and then just call into the MembershipReboot API to take care of the task at hand be it changing UserName or Email or Reset Password.
But like I said I'm not sure. Should we be using Identity Manager middleware? It feels like that isn't the answer as we are writing our own admin interface and from what I could see it is't supporting a password reset via email and the MembershipReboot API says that it does.
Or should we be calling back into our Identity server and making the change? It feels like no because that is for logging into the applications.
Yes, you need to create your own code to allow users to update their demographic info including email and password.
You need to use the UserAccountService -> This code I am using my own CustomUser where I store all the information that would normally be stored in the UserAccount Table
_userAccountService = new UserAccountService<CustomUser>(new CustomUserRepository(new CustomDatabase()));
Then use:
_userAccountService.ChangeEmailRequest();
_userAccountService.ChangeUsername();
_userAccountService.ChangePassword();
If you prefer to have users do this from an email (use when they are not logged in)
_userAccountService.ChangePasswordFromResetKey()
I'm looking at this too but haven't actually implemented it yet. Yes I think you are right that you need to call into the MembershipReboot API yourself. There are methods on the UserAccountService class to perform these functions. See the sample SingleTenantOwinSystemWeb in the MembershipReboot source code.
The IdentityManager functionality is limited but useful for developers to set up users with roles & claims etc for testing, or as a basic Admin tool.
I'm in the process of designing my data model for an iOS application where I'm using Parse for the backend (first time using Parse)
Every user of my application has both private data that should be readable and writable only by the owner of the data and public data which should be readable by everyone.
I'm considering keeping my publicly readable data stored in Parse's built in User object and the private data in another custom object. Is there any downside to this? My app uses Facebook Login exclusively and, thus, when a user is created the authData field is populated with "Facebook: 12345..." Is having this accessible to everyone a security problem?
In this scenario the User object (my public data) would need "Get" not "find" permissions, I just need it to be readable by anyone who knows the objectId. So that rules out anyone just dumping my entire User's table.
I've read through the documentation and the "sensitivity" of each user's authData wasn't clear. I realize that if I were using a traditional username/password scheme it would be a problem, but is it for Facebook login? Any help/tips are appreciated.
EDIT:
I printed an entire user object to the console on a test client (with another, different user logged in) and authData wasn't returned. Am I right to assume that my suggested strategy wouldn't be a problem then? authData appears to be a "special" field that isn't returned if another user fetches it.
I'm working on a small marketing project with Zend Framework, the backoffice of the project is currently made of two controller: a campaign controller and a minisite controller.
The user create a campaign with a form, then he have to create a minisite with a second form linked to this campaign, so i need to get the campaign and the user id when saving the data of the minisite.
What is the best practice and why? should i pass those variables in a session object? or should i pass those variables through a route like :
/backoffice/minisite/create/:userid/:campaign/
Edit: users are logged and authenticated when creating campaigns
Assuming users have to be logged in to do this, you could store the user information you need in a Zend_Auth identity
If not, you could store the data in a normal session var with Zend_Session or redirect to with the route. Either option is good, so it's up to you to pick the one which best suits you and your application.
For passinf information between two controller the best way is to use session to store the values globally . :-)
I'm pretty sure users need to have an account to do these things. If yes, there campaigns and minisites will be associated with them in some way. I'd store and retrieve these things from some form of database.
If you're not having authenticated users and you really just need to pass two variables to another action, use url parameters but be aware of the fact that users can mess with them and a lot of unexpected stuff can happen. Storing in the session is harder to manipulate in that way.
So, if no authentication is involved and the site is public, use the session, otherwise use neither but use storage.
I would use the route option, as you suggest. Using sessions is going to end up being very difficult to test, debug, extend in the future etc.