-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Permission Denied and Content Could Not Be Displayed after a short time on Cookieless Embed #163
Comments
There is not enough information in this issue to determine what the problem is and I do not think this is the appropriate place. One comment I will say is that the inclusion of sessionId with a bearer token in browser is insecure and that raises an immediate red flag. If that session id is a Looker session then definitely do not do this. |
Sorry I missed this reply until now @bryans99 The bearer token is used by the auth on our own server and has nothing to do with looker. I've just included it to show that I need to initialize the embed in that way rather than just providing an endpoint, as some of the behaviour seems to be different in this case as I outlined here. Is there more information I could provide or a more appropriate place for this? I've talked to google support and they advised me to post it here and in the looker community forums as well. |
@cgooding-va did you ever resolve this issue? I'm experiencing the same issue |
@lankers1 Unfortunately I have not. I am just using the regular embed with cookies for now. |
Hi, I can give more details if needed. |
@idukic Thanks for the response! I'm not using OAuth for my embed, but I would still be curious to see your implementation if you don't mind. I didn't think I could re-initialize the session like that without reloading the dashboard, maybe there is some event I could hook into for that too or I could just do it periodically... |
@cgooding-va will pass what I have, hope it helps (note that this is under test and might not be perfect solution, but works atm in my case). Note: Angular component constructor(private oauthService: OAuthService) {
// This will be triggered with refresh token request
// Initialize cookieless session each time refresh token is refreshed and user profile loaded
this.oauthService.events
.pipe(filter((e: OAuthEvent) => e.type === 'user_profile_loaded'))
.subscribe(() => this.initializeCookielessSession());
}
ngOnInit(): void {
this.initializeCookielessSession();
this.createEmbedBuilderForLookerdDashboard();
}
// Initialize the Embed SDK to use a cookieless session
initializeCookielessSession() {
LookerEmbedSDK.initCookieless(
LookerHost,
{
headers: [ Authorization: `Bearer ${current_access_token}`],
url: 'backend/acquire-embed-session'
},
{
headers: [ Authorization: `Bearer ${current_access_token}`],
url: 'backend/generate-tokens'
},
);
}```
Hope this helps! |
We are experiencing a similar issue. It appears that even though the embed SDK is provided with a new
Oddly, we're seeing that the occasional |
When |
Hi |
Hi, |
Just as an update here, I'm not sure what has changed or when but with the latest SDK cookieless embed sessions are no longer timing out for me. |
With Cookieless Embed, after 10-30 minutes of the embedded page being loaded, the embedded dashboard is replaced with this screen:
It looks like some calls around that time are made that return 401 Permission Denied, even though similar calls were made earlier to the same endpoint successfully. Mainly
/api/internal/session/heartbeat
and/embed/dashboards
.For our implementation, we are initializing the cookieless embed sdk like this so that we can include the authorization header in the call to get the session/tokens:
and then creating the dashboard
The acquire and generate calls are being made successfully, and even though I need to manage/cache the tokens on the backend because of this issue, the generate call returns new tokens each time.
However, I did notice that the initial navigation token from the acquire call is being used on the failing
embed/dashboards
call and is in the referrer for the failingheartbeat
call, but I am uncertain about the origin of those calls and haven't been able to see if/how to make changes to the sdk to adjust them.The text was updated successfully, but these errors were encountered: