Can I please know is there a way Spartacus token can be handled in service workers or is there any other approach, Where user cannot view token from session and from network tab? Any documentation really helps.
Thanks in Advance !!
Related
My app is being rejected because it apparently needs cookies enabled. I didn't touch any cookies myself. I use session storage but I see a bunch of cookies in my browser.
It looks to me like they are shopify cookies and I'm not sure how to proceed.
I made the app starting with the code generated by their CLI.
Anyone have any advice. The cookies I see in my. app:
koa.sess.sig
shopifyNonce.sig
shopifyNonce
koa.sess
shopify.granted_storage_access
Are any of these something that I might actually be setting myself? Don't think any of them are any third party I'm intentionally using.
Any suggestions on how I might proceed?
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
So, lately I've been playing around with the Slack API and I kind of figured out how to access the API using the keys available when I use Slack in Chrome. I'm able to access the conversations.history method and download messages. Anyone with API experience know if this is a normal thing? To be able to access the API with a App or standard Authentication token (user tokens are prefixed xoxp- and bot tokens xoxb- and workspace tokens xoxa-2. The token I was using was xoxc- . ) It seems kind of insecure, so my question is, are APIs always vulnerable like this. And, also, I'm guessing that I shouldn't be accessing it like this, and wondering if anyone has heard of people getting in trouble for this or if its expected/ok?
This is the response I got from Slack regarding it.
Thanks for reaching out, I'd be happy to help.
To clarify, xoxc tokens are special tokens that are used by the web client. These tokens are cookie dependent, so even if the token is somehow stolen, it would not be very useful.
However, while we might not explicitly prevent it, using xoxc tokens for the API is not supported or recommended. Our API methods and scopes are meant to be used with Bot (xoxb) or User tokens (xoxp). Workspace tokens (xoxa) tokens are now deprecated, as they were only available to create during a limited developer preview which has since ended.
https://api.slack.com/authentication/token-types
As you continue to use the API, I'd recommend creating a Slack app and creating a properly scoped token as described here:
https://api.slack.com/authentication/basics#scopes
I hope this helps clarify, but please let me know if you have any further questions.
In our current B2B project, we need to use the EarlyLogin functionality together with Smartedit.
Unfortunately, the EarlyLogin prevents a smartedit user from accessing the FrontEnd, after Login into smartedit.
Obviously, because the smartedit user does not have an access token to spartacus yet.
Did someone already resolve that issue and how would you do that?
We are thinking about sending two auth requests, one for smartedit and an additional login request for spartacus with maybe a dummy customer.
Or is there a better work around?
Any help is appreciated :)
Many thanks in advance,
Julian
You can register a dummy customer in Spartacus. Then smartedit user can login as this dummy user in Spartacus.
Thank you a lot of for your answer, Weizhang.
Ideally, a smartEdit user should not be forced to login twice.
Plus, we face a lot of issues with smartEdit in combination with an unauthenticated customer in an protected storefront environment.
Anyhow, that will be our work around as well. We do send an authorization request with a dummy customer for the Spartacus storefront, once the SmartEdit user logs in to SmartEdit.
I'm attempting to connect a Facebook Messenger App to one of my pages..
I've connected Facebook Messenger Apps to pages before.
But this is the first time I've received this error...
What gives?
This is a bug and we are currently working on it. In the meantime, please use our beta tier or generate the page access token through our API. To use the beta tier, you can access the following:
https://developers.beta.facebook.com/apps/89000000000000/messenger/
we got same error and here is helpful answer
https://developers.facebook.com/bugs/281723762198561/
In my case, my app was live which was preventing access token generation.
Just go to app dashboard and disable the live checkbox as below: