Cookie Auth for RestAPI?

Cookie Auth for RestAPI?

This question is answered

Is there a way to not have to constantly pass in API keys or headers on the requests to the API?  

I want to be able to run queries in the browser window instead of via webclient requests in code to see results.

Suggestions? :)

Thanks,

Steve

Verified Answer
  • If you are using the 6.0 version of the platform there is a Rest Console sample project in the Platform SDK.  It adds a page to your website where you can test rest requests.  I don't think we have released anything similar for the 7.0 platform at this time.

  • The answer depends if you are working on-site or off-site. If you are working directly on the Telligent Evolution site then you can just call the REST APIs via ajax calls directly with one caveat, you have to add the authorization code header to the requests. See this for additional info:

    telligent.com/.../20911.aspx

    If you're working off-site then you can still using ajax requests if you're using it from a site using the same domain as your Telligent Evolution site: like you are on tools.mydomain.com and your Telligent Evolution site is on community.mydomain.com. If you are using forms auth then you may have to update the cookie to use the wildcard domain so that it is accessible from both sites. The accessing user will have to be logged into the Telligent Evolution site first. You will still have to send the authorization code header so see the doc linked above.

    If you are working off-site and not on the same domain then the only option is to make the REST calls with code, for example using webclient as you stated. But you can make things easier by writing a proxy to make those calls for you, adding the authentication pieces etc. Then just call your proxy from javascript like it was a local REST endpoint.

    This will provide more examples of authenticating in general:

    telligent.com/.../how-to-authenticate-through-platform-apis.aspx

  • Right. There is no way to call the endpoints directly in the browser and there is no way to disable the requirement of the authorization header. If you're just testing then your best bet is what Matt suggested, the REST console. It is fairly easy to setup and will effectively give you what you are looking for.

    telligent.com/.../20903.aspx

All Replies
  • If you are using the 6.0 version of the platform there is a Rest Console sample project in the Platform SDK.  It adds a page to your website where you can test rest requests.  I don't think we have released anything similar for the 7.0 platform at this time.

  • The answer depends if you are working on-site or off-site. If you are working directly on the Telligent Evolution site then you can just call the REST APIs via ajax calls directly with one caveat, you have to add the authorization code header to the requests. See this for additional info:

    telligent.com/.../20911.aspx

    If you're working off-site then you can still using ajax requests if you're using it from a site using the same domain as your Telligent Evolution site: like you are on tools.mydomain.com and your Telligent Evolution site is on community.mydomain.com. If you are using forms auth then you may have to update the cookie to use the wildcard domain so that it is accessible from both sites. The accessing user will have to be logged into the Telligent Evolution site first. You will still have to send the authorization code header so see the doc linked above.

    If you are working off-site and not on the same domain then the only option is to make the REST calls with code, for example using webclient as you stated. But you can make things easier by writing a proxy to make those calls for you, adding the authentication pieces etc. Then just call your proxy from javascript like it was a local REST endpoint.

    This will provide more examples of authenticating in general:

    telligent.com/.../how-to-authenticate-through-platform-apis.aspx

  • Well yeah thats kind of what i'm getting at (point 1)...I want the cookie being there to be what just lets the rest work in the browser so I can view the live JSON instead of having to add headers in fiddler, or in code (know what I mean)?

    We're a 100% private site, so not really worried about hackers :)

  • Right. There is no way to call the endpoints directly in the browser and there is no way to disable the requirement of the authorization header. If you're just testing then your best bet is what Matt suggested, the REST console. It is fairly easy to setup and will effectively give you what you are looking for.

    telligent.com/.../20903.aspx

  • Ok thanks guys :)

  • Mind if I just do a follow-up and ask if this is on the roadmap at all?  Like if I am authenticated, re-sending the header details on every request is unnessesary (wasting bytes when the checks should happen in the API)...its also way WAY nicer to play around with a rest API in the browser than this test app...the browser essentially is your test app (know what I mean)?

  • It is not  a roadmap item no.  The header should be sent on every request for security reasons(unless in Evolution where we can detect your login).  In 7.0 we have a secondary option of using Oauth in place of Api keys, but still requires token data be sent on every request which is standard.

  • Regarding in-browser REST API usage/experimentation:

    I find it helpful to use the built-in ajax wrappers instead of $.ajax.  These have the advantage of automatically embedding tokens as well as the proper HTTP method header for PUT and DELETE requests.

    telligent.com/.../31462.javascript-and-ajax.aspx

    Alternatively, if you do not want to use the Evolution ajax wrappers, you could use jQuery's preFilter method to automatically inject headers before all $.ajax requests.

  • The reason we require resending the Authorization Code (even when you have your authentication cookie) is a protection against XSS and CSRF attacks.  When you're already logged in, your login cookie gets automatically sent whenever the browser makes an HTTP request, so potentially an attacker could trick the user's browser into making requests to the API without the user realising it.  By requiring the authorization header to be copied into the request headers from a cookie value (which the browser will only let you read from the domain the cookie was produced on), we help protect against this by ensuring that any 'auto authenticated' requests originated from your community's domain, not some malicious domain.