I need some idea about this problem. I made an application which has login and logout functionality. I need to seek a solution when people logout the system, they new user must allow only after two hours.
I can do it with using internet. It is so basic. I can take logout hour, and when user tries to login, I can check the hour on internet but I don't wanna use this solution because, there is no guarantee for every devices have internet.
I can take offline clock from phone. However, in this time, user can change the time and pass the protection quickly.
Is there any idea about this solution? How can I solve it in IOS and swift?
You can listen to UIApplicationSignificantTimeChangeNotification if your app is in foreground/suspended state. But if your app is killed, you won't get this notification.
So, the best way to ensure that user doesn't login in the next 2 hours is to rely on a source of truth that the user can't change i.e. your backend.
Store the time when the user logs out.
Ask your backend for the current time on every launch
Compare it with the the logout time when user tries to login again.
Related
I'm currently working on a PWA and noticed that the overall experience would be awesome for the users, if they do not have to sign-in every time they open the app.
I've noticed that on native mobile apps, the user stays signed in unless they decide logging out of the app.
I could think about the following approaches -
Make the session time super long; say 30 days or 180 days. I'm not aware of the downsides of this approach.
Create a cookie that says that auto-login link and use it to authenticate the user automatically when they open the app.
But there could be a way better approach than this; and I'm curious to know about it. Can someone help?
Well depends on your current user session algorithm, websites like facebook keeps me logged in for years, you might want to use
Local storage (Indexed DB) to store the user's data only update them asynchronously ,
Cookies, set a (x months) cookie and validate the cookie if it exist probably with the user's data,
This would be preferably done with your server side language and not client side.
I am using Twitter digits to log in/authenticate users in my Swift app. Essentially, I just want users to not have to enter their phone number and then enter the 6 digit verification code, every time they open and close my app. I can't find any documentation on this particular point that explains how this is accomplished? Is this handled behind the scenes by Twitter Digits, and if not how do I do it?
I'm not so much familiar with native Swift applications but I'm using local storage approach in Phonegap development.
You should store the username and password value in local storage at first time, then you need to check if username and password in local storage are set when user opens your app again.
If yes, log him/her in with current stored datas. If not, just forward him/her to register part of your app.
You may take a look at how to use local storage in Swift: How to save local data in a Swift app?
I'm writing an app for a retailer, but my client wants that once that the user has logged in the app does not let him/her log out.
My question is: Is this a permitted behavior on Apple apps? Will it get rejected? I've been looking up for a policy related to this, but haven't found anythin that either allows or denies this.
Thanks in advance.
You cannot prevent the user from just killing the app. But she does not necessarily be logged out. If you mark her as "logged in" by means of some persistant store (such as user preferences), you can have him be logged in automatically next time she starts the app.
This is a design that I have seen in many apps. I do not think that it would get you rejected. The user would have to delete the app completely to log out.
One possibility: put a "change login" option into the preferences. At least on iPhone, that is very far away from the app, at the bottom of the settings app which most users never find. Even then you could only let the user be logged out completely once she is logged in with a different valid login.
My recommendation: don't take the control away from the user. Explain to your client that there is a balance between marketing necessities and the danger of annoying important customers who might unduly amplify negative sentiments. Accomodate the needs of your client by making it a bit tedious to log out - but not more.
I want check how to know user is using my application facebook
Example: One user go to application page, i set user online, when user close application page, i set user offline
Thanks.
If you haven't heard from a user for some time, chances are that he closed a page with your app.
Memorize last time a user did anything in your app, and set a timeout. If N minutes later there are no new actions, you mark him offline.
I am designing an iOS application where a user is presented a "sign out" button as the client wants that to be there.
However I am having a tough time working through the logic.
Should I:
1). exit the application at that point since the entire app runs on the premise of authenticated web service calls. (if so how do I make my app exit? )
2). Take the user to the initial splash screen where he/she is given the choice of login/register. (if so how do I reset the app back to initial screen?)
I know what I am asking is confusing so I hope I am making sense.
Exiting from the app is not recommended. It would give the feeling of app crash to the user. You may use the second approach of sending the user back to the initial login screen after he sign outs. If you are using a navigation controller based approach you can try using popToRootViewController method of going back to the login screen(assuming login screen is your root).
Exiting the app is definitely not a good option. I would suggest you take the user back to the page where the user has the option to login or register. As an end user if he/she want to sign in with a different account if he/she can, it would certainly be the best option. No user would want to exit the app and launch it again to use them.