myglos user management

[tslawecki]

Kelli Paige would like other products (Boaters' View, Great Lakes Buoys, etc.) use myglos user IDs to better track users across products. How can we best do this? Is there an API available or needed that allows authentication against myGLOS outside of the main portal?

I'm guessing that @Bobfrat or @kknee are best able to answer, maybe chat about this next call? Or sooner?

[devrap]

Right now, these are technically trackable in GA in the "User ID View for all glos.us products" view, which specifically only tracks logged-in user activity. This is currently only applicable for Boaters, because boaters.glos.us is using this universal glos.us property and greatlakesbuoys.org, having its own domain, is using its own unique property (on the glos.us account).

I do think we could add an additional GTM tag importing the universal glos analytics property to glbuoys to help us better track this flow, if you're interested. @Bobfrat and @gitchrisadams may have feedback on that. We would need to make sure that GLOS is not then double counting that traffic. It would mean a huge leap in the universal property's traffic and also it has its own domain-specific property.

That said, so far, we have only 42 users and 148 sessions (sessions can mean multiple visits per single device) from 6/1/17 - 3/8/18, so there's not a lot to go on. Here's a pdf of a behavior flow sampling. [Note that "/" is portal.glos.us here and not glos.us, and several of these links are now deprecated products that have redirects. It's likely that these 1-2 users were capturing internal testers, possibly myself.]. Analytics User ID View for all glos.us products Behavior Flow 20170601-20180308.pdf

[tslawecki]

Here's the draft use case:

GLOS would like to allow users to log in to many (all?) products so that we can tie specific users to particular product uses, and, where approriate, to restrict access to certain "member-only" features. So, here's my first cut at desired functionality:

1. Log in - product gets user ID and password from user and passes it to API. API returns false/null (no user/password combination found) or a token (perhaps some form of hash based on user ID and timestamp?)
2. Validate - product sends a token to the API. API returns user name (token is valid) or null/false (token is not valid)
3. Add user (MAYBE) - as an alternative to requiring users to sign up through Data Portal.

What I'm imagining at this point is that:

• Users can log in from any of several products using #1
• Token is either passed in URL or stored in a cookie (?)
• Token has a time limit (?)
• Tokens for permalinks need to be discussed. Perhaps the limit is that you have to have a user ID to create a permalink, but anyone can use them?
• There may be other settings we want to store in a user profile; for starters, perhaps we assume that these are only accessed through the Data Portal?

Including @tredder75 in the discussion as well ...

[kkoch]

My two cents on permalinks is just that is how they work now. Must have user ID to create but can share with anyone. So we would want (I believe) to either keep that functionality ...or... we would want a way for super users (e.g., dmac) to create permalinks that could be shared.

[tslawecki]

So reading a bit more online, it looks like cookies + OAuth is a common solution ... would that fit with both OceansMap (@kknee?) and the download tool (@tredder75) ?

[kknee]

@tslawecki we could implement OAuth for Oceansmap but it's not trivial.

[tslawecki]

@kknee, is OAuth necessary? I pulled it out of some dubiously quick web skimming. I expect it's more than sufficient for the use case above, is it necessary?

[kknee]

@tslawecki, OAuth is probably not necessary. @Bobfrat will join tomorrow's call and discuss how our user mgmt works now and whether it's worth exploring using it in GL buoys.

[kknee]

quick documentation of recent conversations - we will use the existing portal user management. @Bobfrat will send @tslawecki and @gcutrell some code snippets for implementing