I am making an andriod app with a login screen that will store simple user info.
As a test i have used a tcp server VB.net on my home computer and am able to connect and login.
client connects
server checks client name
gets the password and if it is correct returns a session that is valid till the session is ended.
Is there a better method?
thanks
Check out Firebase for user authentication. The main advantage is that it is easy to setup and clean. It allows users to login via username/passoword, Google, Facebook, Github... etc. Check the below link to find out more.
https://firebase.google.com/docs/auth/android/firebaseui
Related
I have a web application setup to handle webhook requests from an Actions-on-Google/Dialogflow application using the Google Assistant. Users don't need to sign-in to a google account in order to use my web application and I'd prefer to keep it that way, so that users can sign in with any email address.
I also want my users to be able to interact with my application using the Google Assistant, and be able to access personal/contextual data via the assistant (i.e. when a speaker says, "what's on my shopping list", the web app needs to be able to know what my means).
Currently, I have this working by using my web app to issue a unique short code to my user (in the web app UI) and then with an intent on the Assistant where the speaker says "My code is 1-2-3-4" and then my web app can identify the user from then on (by saving the userId from the webhook request to whatever user got the short code 1234 and then using that userId to lookup the user on each subsequent request.)
My question is, is there a better way to do this? Ideally, in my web app, I'd like to have something like an "Authorize Google Assistant" button, which would then link the user's google account to their web-app account, so that the conversation on the Assistant is seamless.
Has anyone done this before?
Thanks
This is the perfect use case for Account Linking with the Google Assistant.
From your users' perspective, they will start to use your Action. If they're doing so through a speaker and they haven't linked the account yet, they'll be directed to a mobile device to do so. On a mobile device, they'll be redirected to a page on your website where they will been to authenticate themselves and authorize your server to let them in through the Assistant. Once they have done so, they won't need to log in again, the accounts will be linked, and they'll be able to use the voice Action without further obstruction.
From your perspective as a developer, you'll need to setup an OAuth2 server (I suggest the code flow). That login process I mentioned is the first step in the OAuth dance, and will end up with you issuing a code to Google. They will then exchange this code for an Auth Token (with a limited lifetime) and a Refresh Token (which does not expire). They will periodically use the Refresh Token to get new, valid, Auth Tokens for this user. When the user issues a voice command, the Auth Token will be passed as a field in the JSON to your fulfillment server, and you can use this to verify who the user is and that they are authorized to use your service.
In IBM MobileFirst console, we are able to set Application Access form "Active" to "Access disabled", then the app will be disallow to access to the MFP server.
My question is, can we disallow user to access to the app itself ? [For example: once user launch the app, the app will pop out a message to tell user to download new version]
Is there an client side API for detect whether allow user access to the server ?
My question is, can we disallow user to access to the app itself ?
[For example: once user launch the app, the app will pop out a message
to tell user to download new version]
This scenario is exactly what Remote Disable is doing. You have v1 and v2 deployed on the server and you want to force your user(s) to upgrade from v1 to v2, so your set remote disable on v1... and then the user(s) are forced to confirm and upgrade.
Are you asking to do this only for singular users instead of for everyone at once?
Assuming your have implemented authentication on your application, since you know who is logging in to your backend system then you should be able to customize this by implementing the server-side code to also query the database for the version the specific user is using (you'll need to also make sure to enter this data to the database, I believe), and based on the result to have custom client-side code to fail the login and point the user to the App Store.
As you can imagine, this is not available out-of-the-box...
What is not sufficient with Remote Disable?
I am developing an hybrid mobile application using ibm mobilefirst platform.
I am using the custom authentication module example to implement the login module. The problem here is when the user closes the application the app gets logged out.
Is there anyway that I can implement so that the user will not be logged out unless they opt to click on logout button. In simple I am trying to achieve something similar to Facebook remember me option.
You could do something like this (very rough idea):
As part of your authentication flow, if the user has passed the authentication - store in either localStorange or JSONStore a "token" that will basically state that the user has previously logged in. Also save in the server's database using userPrefs something to validate the token.
Whenever the app launches, it will attempt to connect to the server. The environment will be protected with a securityTest so that the server will present a challenge - if a token exist it will attempt to verify it, if there is no token, a login form will display instead.
Assuming this is a first-time launch, if the login passed successfully then store a token in the device and store in the database its "public key"
The next time the app is launched the challenge will be presented again but this time, since we have a token - it will attempt to verify it. If verified - don't present the login screen, skip the rest of the authentication flow and display the secure content
Something like that...
Perhaps to create a 'better' user experience, on app launch also extend the splash screen duration while you're checking for the token, This can be done using this API method.
On logout, clear the token from the device and server.
Is it possible to achieve Azure Active Directory authentication without going to browser window? I will have username and password via the mobile app login interface.
I need to achieve below scenario:
Use open mobile application (ios/android)
Enter Azure AD username and password to app login screen - e.g. user#tenant.onmicrosoft.com & password
I pass those information to .net web service - which need to call some Azure AD api to validate user credential before proceed to perform other business logic/make database calls
Any recommendation? I DON'T want user to redirect to any login window/page as this will not be good user experience.
I have already checked few different articles but not satisfactory response yet.
Thank you for your time.
I believe below link is helpful.
http://www.cloudidentity.com/blog/2014/07/08/using-adal-net-to-authenticate-users-via-usernamepassword/
I want to know what are the best practices, when using Worklight:
To Logout
To Maintain the user logged in, after application relaunch.
To login a user directly after an account creation
I am using Worklight 6 authentication, with a custom login module, for an Hybrid App (HTML5)
If there is a sample doing all these feature, it will be great, otherwise, any code snippets and advices should help me.
Thanks
Can't exactly say that these are 'best practices', but this is what I would do in these situations:
To Logout
Don't have much to say here. Clear anything and everything that the user could use to access resources on the server, including cookies. As you probably know, the login modules come with a logout function call where you can perform these operations.
To Maintain the user logged in, after application relaunch
After the first login, use some local storage mechanism, such as JSONStore, in order to save the credentials. JSONStore can encrypt all data saved locally as well. When the user starts the app, instead of prompting for login credentials, check the local storage to see if the credentials already exist and then send them to the server to log in.
To login a user directly after an account creation
I'd use a similar approach as above. When the user sends their account information to the server, save it to local storage. If the account creation was successful, then the server can send a success response to the client which can then automatically send the credentials back to the server to log them in. If the server sends a failure response, then the credentials should be deleted from the local store and the user will be prompted to try to register again.