I'm new to PWA and had this question bugging me. If a user clears out the browser data, will it also clear out the data which is stored by a Progressive Web App, as it depends on the browser for it's execution?
Yes it would. This is confirmed by a Google Engineer in this post:
When a user clears their browsing data / cookies, this clears all site
storage which includes the SW cache, cookies, local storage,
indexeddb, and any other local caching system.
Note this will also unregister all service workers, meaning you won't
be in a scenario where your service worker is registered and
controlling a page without the any of the cached assets from the
install step.
Related
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.
We noticed a white page blink when page refresh happens on site when the user is logged in.
Also, we know that transfer state is not happening when the user has logged in and this is implemented intentionally since user data will be loaded again anyway.
Then we enabled transfer state for the logged-in users and there is one issue regarding acces_token.
Problem happens when acces_token becomes invalid and the page refreshed, so too many requests are made with the old acces_token (not an endless loop), and it's noticeable that acces_token changes more than a couple of times at that moment.
We assume that cms components make additional requests with the old token and we want to fix this somehow.
We are using Spartacus version 2.1.4
Any ideas on how to fix this?
Let me know if any more info is needed on this.
Thanks in advance.
This shows what is happening after you refresh the page when access_token is expired.
Network tab
I believe it's possible to face such issue when enabling transfer state for logged-in users. If you think it might be a bug or at least good candidate for a feature request please create a ticket: https://github.com/SAP/spartacus/issues/new/choose so the info for reproducing the issue will be provided.
Can you share what's the use case for enabling transfer state for authenticated users?
It might not be exactly the same case but some people deal with similar problem (flickering with SSR enabled for authenticated requests) using cookies:
send token to server in angular universal
Angular universal flickring with Transfer state
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.
I read all similar questions without arriving to the point.
I have a node instance and it runs on my "index.js" only in my local machine.
I have to take a cvs and put on new google sheet.
I have "credentials.json" in my project. Google say me "incorrect redirect_urls". But I cannot put a redirect url since it's a node script.
And I do not want to pass in a browser for a login. This because maybe tomorrow I will put the same script on a real server.
If you are trying to use the Google Sheep API I'm pretty sure you are not getting the results you want. ;)
Assuming you have enabled the Sheets API in you project, and you plan to use a server to deploy the application, then you need to configure you consent screen accordingly.
During development you can use localhost as a redirect URL, which will enable you to test the app.
You should have a read through this help article to correctly set up your OAuth credentials and consent screen for each type of project.
I have the following very specific bug in my web application, caused by a curious interaction between the History API and the way Chrome caches pages.
User A logs in and uses a page like /home on the site. This page is an SPA type page that uses the History API to maintain a history stack as you navigate within the page. So as you do stuff, the url may change to /home/with/new/state This page also has a message like "Hello, User 1" on it.
User A logs out of the application.
On the same computer and browser, User B logs in and goes to /home, /home/with/new/state. Again, this is not a true navigation, just modifying the url via the history API.
User 2 clicks some link to navigate (for real) to another page on the site.
User 2 clicks the back button
The browser goes back to /home/with/new/state, but to the cached version that still says "Hello, User 1" on it.
Naturally, this is really confusing for users.
I can fix this by setting a more aggressive cache-control policy, forcing a reload of the /home page, but that would increase bandwidth to the site. The vast, vast majority of the time, the existing caching is fine, because the user isn't changing, so I don't really want to do this server side, for all users, always. It also is only an issue in Chrome; somehow the other browsers handle this correctly. I'd prefer a mechanism to bust the cache ONLY when I have this situation of a user change.
How might I accomplish this?