I am writing an app and would like to do the following: When the app is first used it prompts the user for a username given at the time of purchase. When entered this is then stored and cannot be changed.
I am unsure whether this is possible or if it is what method I should use to store it. I am right in thinking this is one for KeyChain?
Any advice much appreciated.
Related
I would like to store one user preference per iOS and android device in a database.
Ideally it would be per user but as I don't want to maintain a login system. I want to do it this way.
How can I do this?
Note first that you can use the anonymous user system to create users for you and you could look at using that. You could also create a real user with randomly generated (UUID) username and password which are then stored in the keychain.
Alternatively, use the installation which is created for each device.
I have an app that uses parse.com as backend.
If I want to store information about user's in-app purchases in table there, how can I be sure that some guy is not going to create a simple app where users of my app can log (like in my own) in and write in parse-tables whatever they want (for ex.: that they made in-apps when they really didn't). This info is used to give the user access to app's features so it's important that the user really paid for that.
Don't make the table name public knowledge, so don't ever access it directly from the app, always use cloud code. Pass the cloud code some salted hashed details to verify against, and do the verification on save of any new objects being added toot that table with a before save hook. Drop any new objects which don't pass the test.
We have merchants logged in to a system, from which we want to link them to our Magento instance with some kind of admin token that will log them in directly without them having to manually login.
I see the rp_token field in the admin_user table but that appears to be related to a password reset, which probably isn't what we want.
Have done a bit of searching, found this thread which is related but is dealing with secret keys specifically (which will probably be my second challenge to resolve after resolving this one).
I'm guessing this isn't supported in core, but maybe there's a good extension out there to do it?
Or if not, what would be the best approach to implement? I'm guessing there is probably an event I could hook to look at a GET or POST param (which maybe could be a hash of the username and hashed password), then bypass the normal login() method which relies on username and plain text password.
That feels like it could be a little risky though? Any thoughts?
That feels like it could be a little risky though? Any thoughts?
This is extremely risky, but it can be done safely. I can speak on a similar issue I had in developing QuarkBar, an administration bar for Magento that is set to release this weekend.
So to show the bar, I need to verify the admin is logged in. Unfortunately that's hard to do on the frontend module, since there are two separate sessions. So to get around that I've created a quarkbar_session table. I use OpenSSL to store a secure crypt key once an admin is logged in, that I then check for on each request and match it to a cookie. If it matches, the admin is verified.
It's a little different from what you want of course, since I first set the key when the admin is logged in (it's an observer event). But it should get you started.
Source (NOT ready for production, use it for ideas): https://github.com/zschuessler/QuarkBar/tree/master/app/code/community/Zaclee/QuarkBar
Also, note that I'm storing the secure key so that I can access the admin backend. The solutions in your link say to disable it. You don't have to, check out QuarkBar for implementation.
I am making a bookmarklet, which calls a Google App Engine app. The GAE app uses login information, which I want to store in bookmarklet, so when user first clicks bookmarklet,it asks for login info, but from next time onwards it automatically supplies it.
The difficulty of a bookmarklet directly storing data is that it can only store data in cookie or in localStore, both of which "belong" to whatever page it is currently on. That means it won't work again the next time you use it on a different page, and it also means the page you are on can access the data, which is generally very bad for security.
There are two basic ways your situation is generally handled. The two main ways are:
1.) The application used keeps the user logged in with a cookie. The login information is not stored in the cookie; only a session ID is. This is like when you return to many popular websites, you don't have to log in again. Very often these types of bookmarklets open a small popup for the user which contains a page from the app. If the user is not logged in, the app prompts the user to login first. The bookmarklet in fact knows nothing about being signed in or not.
2.) Each bookmarklet is custom created for each person. So my bookmarklet would be different than yours. The difference is simply that mine will contain my login info in the code, and yours will contain your login information in the code. In fact we would each have to login to the app first before we can get our own personalized bookmarklet.
Generally, option 1 is better and easier and more secure.
If I understand it correctly,this Might help you. http://ajaxian.com/archives/whats-in-a-windowname
It allows for storing data in windowname in JS. Allowing for access of up-to 2 MB of data (A lot more than cookies can hold) and I believe can be used across tabs...
I have an app which asks the user for a username and password which I want to be saved (so the user doesn't have to reenter his data on every launch).
Of course I need to acces the username and password on the next application start. Can you tell me how to do it?
One more thing: the username (and pw) is saved in the AppDelegate but I need it in a different class later..
The proper place to keep a username/password is in the keychain. It's made easier with open source wrappers such as SSKeychain.
The way I suspect you want to do it is with NSUserDefaults, which you can read about in the Preferences and Settings User Guide.
Either way you can get at the information quite easily from elsewhere in your application.
But you really should do it the first way.
Give it a try and come back and ask a more specific question if you can't get it to work.