I used redux and I want to fetch my API using the cookies item like this:
import cookies from "js-cookies";
api/get_liste/${cookies.getItem("moncentre")}
when I run my app, ${cookies.getItem("moncentre")} is null.
My codesandbox: https://codesandbox.io/s/ecstatic-rubin-tf56r?file=/src/App.js:157-212
How can I fix it ?
So the problem here is, you never set a cookie in your app and then try to get the cookie that never exists so it will return null since there is no value for it in the browser cookies.
In order to set a cookie, you should do this (according to the package provider):
cookies.setItem('_code_sandbox_key', 'Cookie did set.')
The other thing that you facing is the warning that you get in your dev tools, so according to this doc, this console warning is not an error or an actual problem — Chrome is just spreading the word about this new standard to increase developer adoption. To fix this you should add SameSite="none Secure" (and then clear all your cookies with the dev tool) to let the browser know the script is not related to your site and that it is a third-party library that you are using.
<script src="https://kit.fontawesome.com/a076d05399.js" SameSite="none Secure"></script>
NOTE: You can follow this thread for more information.
I have gatsby blog, and after I create a new post, and build static files, upload them on my hosting every user has to do hard refresh on my blog to see changes.
How to make auto refresh on next visit after uploading new build?
Another reason for this behavior was in my case the service worker as implemented by gatsby-plugin-offline.
Service workers are programmed to update while navigating. The problem is that when a user visits home and does not navigate any further no UPDATE will be visible. You esssentially never see an update if you have one-page website because there is nowhere to navigate to!
If you want the page to refresh automatically and invalidate the old cache, you need to trigger it. If you have gatsby-plugin-offline in your gatsby-config.js, add this line to your gatsby-browser.js
// trigger an immediate page refresh when an update is found
export const onServiceWorkerUpdateReady = () => window.location.reload();
Here some background information about this issue from the official github repository.
As #coreyway pointed out doing this automatically can be problematic. I argue that this behavior is still better than being stuck with an deprecated website version. If you are concerned about the UX the linked GitHub issuee discusses a solution to let the user trigger an update via click on a update notice message.
You likely have HTTP cache-control headers on your .html files that are telling the browser that they're safe to cache. You want to remove those cache-control headers, or at least configure your HTTP caching to require validation (must-validate). You'll want to do the same for your page-data.json files if you're using Gatsby v2.9.0+.
I have recently cloned a sample project on GitHub jwt-spring-boot-security-angularjs
I understood most of parts of it but there's something I don't really get that is when I refresh my browser I get logged out
I tried adding using session storage
$http.defaults.headers.common['Authorization'] = $sessionStorage.loginSession;
I put this line of code to the home.js which run at initialization but still ends up logged out when I refreshed the browser
any ideas? will be helpful if its explained thoroughly
I have a pretty basic Angular app.
When I try to run it in the browser, the page is blank. But no errors show up in the Chrome console.
Could this have been turned off somehow?
UPDATE
I found the problem to be that I gave angular.module(...) a variable name, but forgot to update the chained calls with the variable. So it looked like this.
var app = angular.module(....);
.config(..);
However, I'm still wondering why I didn't see that error in Chrome
The simple thing of calling FB.init (right before </body>) and then FB.getLoginStatus(callback) doesn't fire the callback function.
After some debugging, I think the SDK is stuck in the "loading" (i.e. FB.Auth._loadState == 'loading') phase and never gets to "loaded", so all callbacks are queued until the SDK has loaded.
If I force-fire the "loaded" event during debugging - with FB.Event.fire('FB.loginStatus', 'loaded') in case you're intersted - then the callbacks are invoked correctly.
Extra details that might be relevant:
My app is a facebook iframe app (loaded via apps.facebook.com/myapp)
I'm using IE9. The same behavior happens in Chrome
The app is hosted in http://localhost
What's going on? Why is the SDK never gets to loaded?
Thanks
UPDATE: Just tried it on Chrome and it worked (not sure why it didn't work before). Still doesn't work in IE
I had this same problem in Firefox 3.5 on Windows, but only on the very first log in to the page (probably because it was a slower machine and there was some weird timing issues going on).
I fixed it by forcing FB to refresh the login status cookie every time it checks:
FB.getLoginStatus(callback, true); //second argument forces a refresh from Facebook's server.
Without "force=true", sometimes it wouldn't fire the callback.
I had the exact same problem, and I solved it disabling "Secure Browsing" in the Facebook Security settings. Keeping Secure Browsing on forces the pages as "https", but I had no "Secure Canvas URL" set up, and this gave me a lot of errors in the console as well.
Hope this may help someone :)
In my experience, getLoginStatus() never calls the callback in Firefox when third-party cookies are disabled.
The original poster mentioned his application is hosted on http://localhost. I've never had luck with that, and believe it will cause problems.
Just today, I've had problems where getLoginStatus is not calling the callback on any browser, unless the user is actually connected to the app! I'm hoping this is a bug on facebook's end that they will solve.
Yet another possibility for FB.getLoginStatus not firing its callback is when using a "test" user account that has not been authorized to view that application. Its pretty bad that facebook doesn't give you any error messages.
I have also seen failed callbacks on bad appIds and redirectUrls.
I also ran into this issue specifically in Chrome. I tried calling it on page load and after a user-initiated action with no success.
It turned out that it was not a cross-domain issue. The getLoginStatus() call was being blocked by the Un-Passwordise extension in Chrome. As soon as I disabled the extension, it worked perfectly, even on page load.
More info about this issue here: Chrome-only cross-domain scripting errs in Facebook iFrame App upon FB.Login(..)
I understand that this question is a little old now, but I ran across it searching for solutions.
Double-check what you have set in your Facebook app configuration under the section "Website with Facebook Login". The Site URL domain must match the domain your page with the FB.getLoginStatus (and other related auth Javascript) is served from.
After hours of struggling, I realized that I could not reuse an existing app configuration I had on a new server and had to create a new app to handle the website login for this new server.
The other answers are probably equally valid in your specific case, but since there may be others like me who have struggled for a while on this, hopefully this gives you one other place to check. Making a new app with the correct Site URL was the answer in my particular case.