Third Light Developer Exchange

François

Member

Registered: 2017-06-12

Posts: 10

Issue with CMS Browser

(migrating from IMS to CHORUS)

When using a API key produced from "Site Settings" in CHORUS, the CMS browser is working well from another Web application.
Using it, the browser first shows all spaces and allows navigation everywhere... (which turns out to be a true security issue, but this is not the topic of this messag ; the impersonateUser futur REST feature should solves that).
Same behavior than in IMS. Great.

When using the same javascript code with an API Key produced at a space level (in a selected Space, menus: Manage Space, Action > API Keys), the CMS Browser crashs with an error on the REST API /rest/v1/users/current (as described in my Chrome javascript Console). This call seems embedded in the CMS Browser code. We are using loginWithKey to get a valid session token).

I suspect the first API key to be associated to the Admin account (there is a "user") and the second to be associated with ... nobody.

Is there any way to solve this issue by declaring a owner of a space ? how to proceed ? Is it a bug (Thirdlight Staff) ?

Thank for any help,
François

Barry Chuckle

Member

Registered: 2015-01-06

Posts: 5

Re: Issue with CMS Browser

Hi François,

The CMS browser isn't really designed for this kind of API key. You didn't mention the details of the error you saw but we suspect it was like this:

{
  "code": 9,
  "message": "WRONG_USER_TYPE (debug: Current user is not a Normal User)",
  "details": []
}

What you could try instead is to create a user with the space set as their Home Space and then create an API key for that user. That API key should then be acceptable to the CMS Browser.

Barry

François

Member

Registered: 2017-06-12

Posts: 10

Re: Issue with CMS Browser

Hi Barry,
Yes, the error is the one you describe.
And yes, the proposal to use a technical account to solve the issue is probably the best for the time being.
When the upload will be available on this CMS Browser again, we will use the impersonateUser api to identitify the user properly.
I am so attached to the principle of user Single Sign-On with no password (smart card instead) that I forgot that a technical account (login+password) could solve our problem.
Thanks a lot!

François