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
Related
I have a website that uses firebase firestore and recently activated AppCheck, it seems to be working okay when I just activated but now I am getting heaps of invalid requests.
This appCheck is only used for the website so I am a bit concerned if this simply means somebody tries to access firestore not in a proper way or if this is something common issue.
Is there any options I can try reduce the invalid requests?
Thank you
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'm currently working on an app where users are able to log in and access their data from Firebase. The app used to just be a Flask app, so I used flask_login to help keep track of user sessions.
However, I'm now trying to use Vue for the front end (including the routing), so technically we will be running a Vue app as well as a Flask app where the Vue app will be making GET requests to the Flask app. I found a tutorial for authentication in Vue. I was wondering if I needed to both this as well as flask_login. If so, how would that look like?
Really late, but since this is not answered, I will give it a go:
I would recommend going with JSON web tokens (JWT). This post probably explains it better than I ever will.
The basic flow would be:
On the [flask] backend every API call that needs protection will have a decorator (similar to #login_required) that protects the resource from being accessed by users not authenticated. For a user to be authenticated they will need to fetch from "/login" and the server will respond with a token, store this in memory. This token will need to be sent with any subsequent API call. When the user logs out, simply nullify the token on the front end.
On my setup, I used flask-jwt-extended and on vue, simply make sure that you have a token stored, if not, render a login modal or popup or redirect to the login page.
Read the post I mentioned to understand the JWT refresh flow.
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?
I'm having a really strange problem. I've written an iOS/Rails app in which users have accounts, and need to log in to perform all kinds of actions within the app.
When the app launches, the app detects whether the user's username and password have been stored. If not, it prompts for login credentials. Anyway, logging in seems to be working perfectly, and the server sends back the appropriate response.
However, when I try to do anything else in the app that requires being logged in, I get an error from the server saying I don't have the login credentials. I didn't think I had to do anything special with the cookies (i.e. I thought they were stored automatically), but maybe I'm wrong?
If some code samples would help, let me know what snippets you'd like to see and I'll post them, but I feel like this is more of a conceptual misunderstanding on my part than anything else.
Any help is much appreciated!
EDIT: I tested the app on my friend's phone, and it works fine. It's only my phone which is having trouble with the app. I looked for any settings involving cookies, but because all the apps are sandboxed, changing settings with cookies in Safari, for example, won't help. I'm pulling my hair out with this issue. I've restarted my phone, deleted and reinstalled the app, and tried changing some of the code, without any success. The Facebook app works as expected, so I assume cookies are being stored in Facebook's sandbox. Only my app seems to be having this problem, but it was working yesterday. Any suggestions?
After you login you need to store the cookie which is returned. It will then be sent with every request afterwards.
Take alook at theses q's:
Objective-C Asynchronous Web Request with Cookies
Managing HTTP Cookies on iPhone
iPhone NSData/NSUrl with cookie