I'm starting to create a lot more features for users in my app. I've run into some app structure issues.
lets say I have User Fooman
Fooman wants to edit his account, delete some objects(wall posts), update his friends list etc.
Fooman is logged in to do all of these. But footman isn't the one using the device at the moment. It's fooman son (foobaby). Foobaby decides to just be a son and delete things erroneously. I have an option for users to delete their account client side. I present them an alert view to confirm that's the choice they meant to select. After they confirm that, another view populates with a 'Destroy' (or delete button) that will delete the User, plus all relations/pointers/data connected to it. Before that button is enabled a password validation check is required so it's not done by a foobaby. However, with Parse, this has proved to be problematic client side. I don't use cloud functions because, well, simply put, at this point in time my app is one platform and doesn't really need to use it.
Is there any workaround anyone has come up with that's quick/efficient, API friendly for validating a textField.text with the [PFUser currentUser].password whilst maintaining security of course.
I code in Objective-C :)
Note: I have tried numerous things but nothing seems to work outside of trying to log them in against the user input (UITextField), which doesn't feel like the right way to do it in my opinion.
I think it's an unusual requirement. The idea of a logged-in user is that the app trusts the user. A persisted logged-in user on the device means that the app trusts whomever is holding the device. So FooBaby is trusted, because FooDad let him hold the phone.
Some apps put up a barrier to establish thoughtfulness, like the Parse data browser requiring that you type the name of a class before you drop it. But this establishes thoughtfulness, not trust. (For a child, I guess it also establishes minimal competence, in case FooBaby knows how to press buttons, but not how to spell).
Otherwise, I can't think of how to do it besides requiring a login, which you mentioned you find unappealing (though you didn't say why). Excluding that, I don't think there's a way to do it without spoiling security with something like keeping an in-the-clear copy of the password.
Related
I know that to delete a Parse user, we have to call the "delete" method on the authenticated Parse User object. However, that only deletes the user in the User table, but not all data related to that user in other tables. Is there a way to trigger this automatically or do we have to implement this manually via some code in the "before_save" or "after_save"?
Also, should I log out the user after deleting his account?
You can implement it in before_save or after_save, but I would go with a hardcoded version of this. It strongly depends on your data structure, but generally, you would have to query for all the objects related to a user and then delete them separately (in background).
I would also log out the user, because due to caching, the app often doesn't realise that the user doesn't exist anymore, so I would go for logging the user out from Parse (even if that logout may fail because there is no user to logout anymore) and log him out of the app by showing him the login screen or whatever you're usually doing.
You see, deleting every information related to a user is a quite time and resource expensive task to do, so usually one simply deletes the user and his private information, and leaves the rest (for example in a messenger app, you would not delete the messages, as you want the other users still to be able to see what they wrote to the - now deleted - user).
I need to create a webpage for a specific customer to use only during certain time frames.
I would like to make this page as secure as possible, by not allowing anybody else to see this page during this time frame. I would also like to make it as easy as possible for this customer to open this page.
My thinking is:
Open time frame
Send customer link via email
Email contains passcode to use to enter the page
After task is complete or time frame expires, the passcode also expires
To me, this seems pretty secure.
My concerns are:
The customer forwarding the email (I don't see why they would do this, so may be a mute point)
There is an inherent flaw in my thinking that I am not aware of.
The time frame is kept in a database. Each user action will have the passcode checked against the time frame to ensure that it is valid.
Is this method secure, within a reasonable degree, or is there a better way that you know of, or an existing technology that deals with this problem already?
As i gather, you want to limit access to third-parties as much as possible. i think you'd want something login-based - have a simple registration procedure with which you can connect the email to a user, let the client choose their own password, give the user rights to access the page, share the link (either use encryption with email or do it with the user account), restrict multiple sessions. Once the client has the information, you can't really ensure that they don't misuse it..
In my Rails App, I made a form_for to allow any visitor to submit their content.
But after submit, I want to ask user, whether they want to register for this site or not.
There are some approach to this:
Redirect after user submits the form, left the initial post anonymous.
Much the same as the first one. But somehow help user to reclaim the post they just make
Store the content in some place first and do not submit. Instead, ask for register. And after register, show the stored content before and ask user to submit again.
Basically, I can implement the 1st method. But it seems just not that good. For the 2nd and 3rd one, I do not know how to reclaim the post or store content beforehand.
Is there a standard way to do this? How can I solve this problem?
For solving the same kind of problem, I chose your 3rd option. For that you can use sessions, it will allow you to keep some information in memory related to a specific connection to your server.
http://guides.rubyonrails.org/action_controller_overview.html#session
There are some ways.
First of all you need to keep in mind that these are different behaviors from which you should chose first and do not let the implementation force you to chose one.
For the second case you can have the id of the post that was created (along with some guarantees that it is an orphan post) and then tweak your register method to also assign a post to a user after creating one.
The Third case can be implemented by storing the post data either to session or to a backend temporary store and retrieve them if needed.
I'm currently coding all of the account management functionality for my site, and have already implemented the account activation and password reset systems by e-mail. The e-mails each contain a link to a servlet (with the appropriate parameters attached to the end), which does all the processing. Tests for the systems have gone well, however I have one question.
If the link's text is the same as its address, is there any reason to include traditional manual activation/password reset page (a page with a form where the request parameters in the activation or reset link would be entered in to the appropriate fields)? If the link doesn't work in the e-mail, the user can always copy and paste it. Is there any particular reason why sites still have seperate pages dedicated to these actions? And should I allow it?
You never know for certain the kind of transformations your email will undergo before being displayed to the person that will eventually use your reset facility. Combined with clueless users this may pose a problem.
An example: Since reset/activation links can be quite long they may be partially wrapped onto a new line after a transformation from HTML to plain text. Inevitably this will someday happen to a user that does not know how to deal with that situation.
Therefore it might prudent to provide the backup method of just entering the code in a text field which on submit performs the GET that was intended in the first place.
You are of course free to decide that your site does not need the business of said type of user and skip implementation of the manual method!
What would be the best way to go about giving users the ability to share a private link that enables anyone who clicks it to view a certain page/document/item that have privacy restrictions in place?
In my case:
A User creates events which are limited to certain groups of relationships in the database (namely: friends, friends of friends, etc.) I have a :before_filter in the event controller that checks the eligibility of the current logged in user to make sure that that user has permission to see the event. If they don't they get booted to the root page with an error message.
However, I want a special scenario to exist where a user can create an event with those same privacy settings and IN ADDITION, be able to share a special link with his or her friends via e-mail, facebook, etc. Those users do NOT need an account (but will need to make one in order to sign up for the event). This is important because there is also a :before_filter in the application_controller which makes sure a user is logged in.
I'm thinking there is something I could do with routing here... Right now I just have the simple /events/72 setup. Should each event have two different links: a normal one, and a "special code" version which enables them to bypass those two :before_filter?
What are people's thoughts?
I agree with David Lyod's answer (separating this concern in a different controller).
But for creating the hash I strongly recommend you salting the hash with some secret phrase.
require "digest"
Digest::SHA512.hexdigest("#{created_at}#{user_id}.mysupersonicsecretSALT")
Doing this it is not possible, without the knowlegde of the secret phrase, to calculate the hashes and test them against your system until it hits an existing one.
If you're handling sensitive data you should not be lazy.
Cheers,
Lukas
I would have a separate controller that uses a hash value to reference the event.
Something simple like the created_at + user_id hashed to create a unique reference.
You could also simply skip the check on a certain action but I would much prefer the first solution .