Live Coding Happy Hour Recap for March 10, 2017 - OAuth Part 3, GitHub API and One Token Per User

#OAuth , #Scripted REST API , #OAuth APIs , #OAuth Tokens , #Outbound REST APIs

Josh Nerius

2 minute read

YouTube video: https://www.youtube.com/watch?v=8_yHYAPDpvw

The live coding team: josh.nerius, ctomasi

This week, we returned to the topic of OAuth and learned how to generate OAuth tokens per user instead of per REST Message/Method. When calling some APIs, sharing a single token between every user in ServiceNow is not always appropriate and instead we want each user to have their own token.

Examples:

  • Calling the Dropbox API and interacting with the currently logged in user’s files
  • Calling the GitHub API and forking repositories on behalf of the current ServiceNow user

Video Index

00:00 - Intro
01:55 - Beers!
03:29 - API of the Week - GlideURI
08:55 - Reticulating Splinesb&
09:34 - Getting back into OAuth
11:50 - Register a GitHub Application
14:04 - Create OAuth Provider in ServiceNow
18:32 - Specifying GitHub brepo’ Scope
22:54 - Got a token! And some notes about “Special Snowflaky” APIs
23:44 - Why this won’t work as is, we need one token per user
24:43 - Examining how the “Get OAuth Token” button works
25:55 - Build a UI Page and implement “Sign in to GitHub” button
32:32 - Understanding the structure of a oauth_credential records and OAuth Requestor Profiles
37:50 - Building a Scripted REST API to handle calls from the UI
45:16 - Call the Scripted REST API with jQuery
56:51 - This is where things break
1:08:18 - We discover the OAuth Profile configured on the REST Message interferes with our code
1:16:05 - Recap of the use case
1:16:55 - Beer ratings, CreatorCon and wrapping up

Resources

Closing the loop on our perplexing caching issue

Near the end of the broadcast, we ran into an issue when trying to actually demonstrate the finished code. As it turns out, the code was actually working the whole time, but browser caching issues got us. Earlier in the broadcast around the 56:50 mark, I entered a username/password into Chrome’s Basic Auth prompt. Chrome cached these credentials and used them for all subsequent calls to the Scripted REST API. Even though we were logging out of the main ServiceNow UI, Chrome treated this differently than the API endpoint we were calling. After clearing browser cache, things worked the way we expected:

  1. Calling the API while logged in as admin in the bJosh’ browser returns GitHub info for the jnerius user

    api-response-jnerius.png

  2. Calling the API while logged in as Abel Tuter in the bBatman’ browser returns GitHub info for the jn-batman user

    api-response-batman.png



Watch out for caching issues!

Comments