I am working on a PWA using Vue.js. For syncing data we use PouchDB on the client and a remote express-pouchdb server.
When starting the application, we want the user to login, regardless if online or offline.
So our idea is the following:
When opening the website for the very first time, the user has to login at the remote-db
All users are synced to the local pouchdb-instance
When the PWA is opened and the client isn't online, then authenticate against the local-db, otherwise the remote-db (and also keep the users in sync).
Is it possible to achieve this behavior?
I've seen some authentication plugins, namely pouchdb-authentication, pouchdb-auth and pouchdb-seamless-auth, though im not exactly sure, if these can be used for our requirement.
You could achieve it by encrypting your pouchdb https://github.com/calvinmetcalf/crypto-pouch
Then if you are offline instead of login you enter the password to decrypt. The problem is that if you are logged out when you open the app offline there is no way you can get user info.
So you need to store user info locally, in a _local document that doesn't replicate. And since offline authentication is not supported, you have to check yourself user/password stored locally. So you will have 2 separate login for online(you can do this easily with pouchdb authentication) and offline.
Personally the best solution is to make a dump of pouchdb on logout. And then delete local pouchdb (data in browser). If you are online, you proceed to standard login and upon success load the dump and sync to remote. If you are offline, check locally stored user/password and again upon success load dump.
Additionally, you can encrypt the dumped database as well.
Related
I have a Google Apps Script deployed as a web app. It is configured to run as me, as it creates and amends events on my calendar and uses a Google sheet of mine as its data store.
There is a requirement that users are NOT required to have a Google (or any other specific type of) account to log on, so I have written a bespoke login function.
The problem I have is reliably identifying the user session.
User properties/cache doesn't work as the user is me for all users.
Is there a way I can identify something unique about the actual user to identify their session?
I understand that web apps run on Google's server and that I have no access to the user's browser so cookies and similar technologies are not an option.
I'm building an application with Vue and Electron, and I'm wondering what the best approach is for authenticating users.
I'm using JSStore as a wrapper for IndexedDB as my database. I'm familiar with using bcryptjs as a means for authenticating users when I create Node backend and have traditional /login or /signup routes.
But this is where I'm starting to get confused. Do I need to set up a Node server to start up when my application starts up? Because given that I'm using IndexedDB, I don't know that it makes sense to have a process of Sign Up --> Request to Node Server --> Send data back to browser
Would I be better served using a different type of database? Could I do something such as adding bcryptjs to the Vue prototype, so that's it's accessible where I need it to work with JS Store? Are there security concerns that I should be aware of with an approach like that?
At this point I'm stuck, and have more questions than answers. I've done some looking around for articles, and I find a lot of content about setting up authentication with Vue, but not within the context of an Electron application. I'm not sure how that variable changes things.
Any advice or direction would be greatly appreciated.
JsStore is client side technology, which means if you are setting up authentication in client side, it will be available only to that device.
Let's understand it more by use case -
Say your application named My Awesome app has authenticaion implemented. User register it and then they are able to use it after registration. They are logging out and signing in again with registration data and everything is working normal.
Here is what wrong with this approach -
User buys another pc and installed application My Awesome app, he tries to login but unable to login because registration data does not exist on their new PC.
Due to some issue, user hard disk crashed & he installed new hard disk. Same thing as above he is not able to log in.
So it is recommended to implement the signin on some server & keep data there.
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
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 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.