Looker API CORS

moebe
Participant V

what does the new feature in 7.10 do?
do you have some usecases for me?

0 9 1,087
9 REPLIES 9

Correction:
This functionality lets specific users authenticate with their existing Looker user account into a third party application. It does not allow for the creation of a total “Powered by Looker” experience where a web app is making background API calls to a Looker instance and serving the results up to a user who is blind to the existence of Looker.

I believe CORS support can be plain-englished to be pretty much this:

Before, you couldn’t make a Looker API call from a browser-based application (like from javascript in a react frontend). The API call would be automatically blocked because of the Cross Origin Resource Sharing policy. Now, you can do that! Does that make sense?

Re: usecases, if you’re building a web app that you hope to power with Looker or bring any data from Looker into, this will probably make you very happy. If you’re not, it won’t impact you very much/at all.

I’m also interested in specific usecases actually. What are you all going to build with this, everyone?

Hey, I actually have no idea how to add URLs to the white list. It’s not obvious where to do this. Any suggestions?

It’s easy enough to turn on the setting itself

It looks like we are documenting this right now, sorry for the delay there. Here’s a sneak preview lifted from our internal documentation.

  • Go to {{ host_url }}/admin/labs page
  • Enable the Experimental feature “ Looker API CORS”
  • Open the Web API Explorer (most often {{ host_url }}:19999/api-docs/index.html )
  • Select the version API 4.0 from the dropdown (3.0 and 3.1 do not have this call)
  • Login with your API client_id & client_secret (or go create them if you haven’t)
  • Use register_oauth_client_app() to define your web app for Looker. API Docs
    (We’re making a UI for this, don’t worry)
  • In your web app, when you want to engage the Oauth login with the interactive user, you send a web request to the /auth endpoint on the Looker UI web service.
  • This will bounce through the normal Looker login page, using whatever login system the Looker instance has been configured to use (LDAP, SAML, etc).
  • If the user is already logged into Looker UI in the current browser (live login cookie state), the user won’t be prompted to enter creds.
    • If this is the first time this user has engaged with this web app, looker will show a disclosure/confirmation page for the user to acknowledge/accept . Are you sure? kinda thing. The description text in the app registration is what will be displayed - it should indicate what the app intends to do with the user’s Looker account. When the user clicks accept, the page will redirect to your app redirect_uri
    • If the user is already logged into Looker in the current browser and has already ack’d the disclosure page, then the Oauth login “bounce” through Looker login will be instantaneous with no visual interruption. boom, done.
  • When the Oauth redirect lands in your app, grab the auth code in the URI params.
  • Make a web request to the /token endpoint on the Looker API web service, passing in the auth code and your app info.
  • A successful response will provide you with an API access_token which is enabled for CORS api requests, but only from your web app domain.
  • The auth response will also contain a refresh_token which you can use later to get a new access_token without user interaction. refresh_tokens have a 1 month lifetime. Store these carefully/securely.
  • all tokens in this system can be revoked by admin action at any time. Apps should always be prepared to fall back to interactive user login (Oauth auth_code workflow).

This is awesome! Thanks so much! I’m going to try it out

Definitely report back! And if there’s any hitches in that documentation, let us know so we can make things clearer.

Hey this actually won’t help me for some fairly obscure reasons. We’re trying to access our own Looker API from inside the extension framework (also new!)

Unfortunately iframes like the extension framework one send an Origin header of “null”, which cannot be safely added to any CORS whitelist.

Even worse we cannot go in and manually update the whitelist to accept the opaque “null” value (even if we wanted to) because of how the whitelist is created (as described in your documentation)

If you could help me get in contact with a Looker developer involved in the extension framework, I can recommend some changes to improve both security and ease of development

I’ve reached out to the folks working on it and will try to get you in contact! Look for an email.

For this case, though— You can call the Looker API directly from within the extension framework, authenticated as the current user. You don’t need CORS to do so. Check out the example extensions like: https://github.com/looker-open-source/extension-template-react for a look at how to do that.

This https://www.npmjs.com/package/@looker/extension-sdk-react#looker-sdk-considerations should also be instructive.

Am I misunderstanding your scenario (you did mention it was obscure)?

Issuing a correction: I seem to have misunderstood what exactly this CORS functionality was intended to do.

This functionality lets specific users authenticate with their existing Looker user account into a third party application. It does not allow for the creation of a total “Powered by Looker” experience where a web app is making background API calls to a Looker instance and serving the results up to a user who is blind to the existence of Looker.

My bad for misunderstanding the intent of the feature!

Really appreciate you going above and beyond here! Don’t sweat it though. The reason I was interested was to bypass some broken SDK methods. SDK has been working out great otherwise.

A number of the create and run query methods don’t work through the SDK right now. This was my attempt to use the “external” API as a temporary workaround