As a community manager, network admin or a developer you may have received a notification from Yammer earlier in the morning today (February 11 2015 for those of us in the Americas) to update JavaScript Origins Field. As an admin, this is what you received: Network_Admin_JS_YammerAnd then developers received this slightly different version:

Dev_update_JSAnd then this evening, Yammer partners received another email notification about this also:

Partner_JS_originsSo Yammer has done a great job communicating this change and trying to reach everyone it may affect, which is definitely most appreciated.

But what does it mean?  In particular if you are a community manager with a non-technical background, JavaScript Origins could be a new coffee shop or something about the history of calligraphy 🙂 But the warning is quite stern that the change has to be made and it’s something about security. Don’t I have apps switched off in my network? And now you’re nervous.

This specific issue that the email is intended for is if you or your developers are using the ‘Sign in with Yammer’ button which is part of the JS SDK (where JS is JavaScript, a common lightweight programming language and SDK means software development kit, shortcuts to help you get your development project done faster). So if you’ve seen this button anywhere on your internal applications, this is likely why you are getting the notification. Sign In with YammerInterestingly, I got the notification three times as detailed above, and none of our applications use this button. So I went ahead and updated all our apps’ JavaScript Origins anyway. Because we’ve never actually populated them. And, just in case ya know. Because on the page Yammer links to in their documentation it says “NOTE: If the SDK is hosted on a domain that has not been registered, your app will not work”.

The good news is it’s a simple change, and here are the step by step instructions.

Step 1 – Find the Yammer applications you’ve created

Go to this URL in your home (canonical) network https://www.yammer.com/client_applications and you’ll find all the apps you’ve created to access the Yammer API. You can also find this option in the (ellipses) … header menu>Created Apps. As a network admin, you may have done this so that your developers could access the API for your in-house applications. So if you’ve ever written an app or had someone do that for you in your company that accesses Yammer, for example to automate the data export on a regular basis, or to allow an app to do sentiment analysis or records management erasing Yammer content after a set retention period, you’re likely to have created an app.

You’ll see a table like this:

registered_applications_yammerImportantly these are the apps that are owned by you. Owned in the sense that you created them, likely at the behest of someone else if you’re a community manager. You cannot see all the apps across your network that have been created, you can only see the ones you created. This is why its a best practice to have the Yammer admins/community managers create the app that is going to be used for QA/production purposes in particular.

You (or any user) in your network can go to your app directory and see listed the local apps that have been deployed in your home network. But even as an admin, you can’t see all the apps that have been created in your organization but have not been deployed to your home network.

Step 2 – Select an app and look at Basic Info page

Click on the name of the app to open the next screen. You’ll go into a screen where you see the Client Key ID/Secret. Ignore tbasic_info_yammer_apphat, and look to the left column where it says Basic Info. Even though the green check mark may look like it indicates you’re on that page, you’re not, so go ahead and click on Basic Info.

This will open the screen that Yammer indicated for reference in their emails. Here’s the page https://developer.yammer.com/v1.0/docs/js-sdk.

Focus your attention on the lower part of the screen, where it says Installation Information. It’s a bit of a misnomer, because you’re not really installing anything in the conventional sense.

app_info_screenThe ‘Redirect URI‘ is the URL of your application that Yammer calls back to when the user is authenticated. The authentication process in Yammer goes something like this, and I’m simplifying,  ‘Hi, I’m Naomi, I have this ID card and secret code to give you Mr Security Guard, will you please give a pass to enter the building?’. Security guard says ‘Ok, I’ve checked your ID and secret, here’s your pass (its called an auth token) but I’ve been told you can only go to level 3 and Mr Pink will meet you there and take your pass’. Mr Pink is your Redirect URI. It’s a security measure to make sure that your auth token goes to the expected place and it must match exactly your application’s domain (at least).

JavaScript Origins – this is the section we’re going to update. An origin is the place you’re going to run the code (your code) from. For the vast majority of cases, that means you are going to enter the https://yourdomain.com that you run the application from.

You need to enter all the places that the code for this app could run from. No wildcards are allowed. So it could be http://locahost:4567 for a developer’s machine, http://qa.yourdomain.com for your staging/QA version of the app, and https://yourdomain.com for the real thing.

Each of these origins should be on a new line and must be exact.

An origin must have a hostname, protocol and a port.

(The real thing always has to run in SSL (the https:// address) otherwise your users will get a warning. And it’s just a good thing to do generally.)

So the hardest part may be getting the right URLs from your dev team to include in these origins.

Click Save. You can update these origins as many times as necessary and have as many as you need to list. You won’t break your app by updating it while it’s being used.

What Happens Next?

According to the notifications, it sounds like that for internal, your-network-only apps, you’ll get a warning displayed if the origins are not specified, after 30 days. After 60 days the Sign In With Yammer button will no longer work.

In the Yammer partner email, I’m assuming that this email goes to anyone listed in the Yammer 3rd party app directory, after 15 days the warning will show. Here’s the screenshot of the warning. Stern stuff indeed.

js_origins_warning_message

I hope this walkthrough is helpful to you, let me know if you have any comments or if I need to add some clarification somewhere.