Need a method to communicate session data to other services

[Patrick Boyd]

Ok, we currently have firebase/php-jwt installed because of Google's API. Here is my proposal. We use that to generate the contents of a client side cookie (call it say "Flipside_JWT"). The JWT payload would look like the following:

{
    "sub": "<username>",
    "iss": "profiles.burningflipside.com",
    "private": {
        "Flipside": {
            "email": "<user@email>",
            "groups": [ "All", "Groups", "the", "user", "was", "a", "member", "of", "at", "login"],
            "sessionIDs": {
                "php": "The PHP Session ID, that way if we screw up the application can fake the php cookie and act for the user"
            }
        }
    }
}

I hope we don't need the session IDs field, but it also let's us eventually get rid of the PHPSESSID cookie and move to the JWT being the only client side token.

@russelltsherman @dahling-jerry Any thoughts? Work for both of you?

[dahling-jerry]

Is there already a notion in the data model of "[e-mail] is the Volunteer Coordinator" or is it just "[e-mail] belongs to the AF group"? If that information is easily stored in a cookie, it would save me from having to create those mapping seperately. Otherwise, I'm happy to do so.

…

On Mon, Jun 19, 2017 at 1:29 PM, Patrick Boyd ***@***.***> wrote: Ok, we currently have firebase/php-jwt installed because of Google's API. Here is my proposal. We use that to generate the contents of a client side cookie (call it say "Flipside_JWT"). The JWT payload would look like the following: { "sub": "", "iss": "profiles.burningflipside.com", "private": { "Flipside": { "email": ***@***.***", "groups": [ "All", "Groups", "the", "user", "was", "a", "member", "of", "at", "login"], "sessionIDs": { "php": "The PHP Session ID, that way if we screw up the application can fake the php cookie and act for the user" } } } } I hope we don't need the session IDs field, but it also let's us eventually get rid of the PHPSESSID cookie and move to the JWT being the only client side token. @russelltsherman <https://github.com/russelltsherman> @dahling-jerry <https://github.com/dahling-jerry> Any thoughts? Work for both of you? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#60>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYiYVx4lXir0t5HncDRr0WhfzYhPDUawks5sFr4dgaJpZM4N-nKe> .

[Patrick Boyd]

Here is the output of the API call https://profiles.burningflipside.com/api/v1/users/your BF username (somewhat truncated and redacted for privacy):

{
  "displayName": "Dahling",
  "givenName": "REDACTED",
  "jpegPhoto": "REDACTED",
  "mail": "REDACTED",
  "mobile": "REDACTED",
  "uid": "REDACTED",
  "o": "Volunteer",
  "title": [
    "VC"
  ],
  "titlenames": [
    "Volunteer Coordinator"
  ],
  "st": "TX",
  "l": "AUSTIN",
  "sn": "REDACTED",
  "cn": "REDACTED",
  "postalAddress": "REDACTED",
  "postalCode": "REDACTED",
  "c": "US",
  "ou": [
    "VC"
  ],
  "host": false,
  "class": "Auth\\LDAPUser"
}

[Patrick Boyd]

So basically you can get titles from the user API (for users that have titles). It's an array because they can have multiple titles (like a CC member and an AF for example). You can also get what groups they are in. I use groups a bit more often in the current code (i.e. they are a lead). You can then use the title array to narrow it down more (i.e. they are the ranger lead). But I was thinking we might need either more groups (i.e. these users are authorized to edit the Ranger team's shifts and approve sign ups) rather than relying on the one lead to do that.

[dahling-jerry]

I think the best default behaviour would be "the ranger lead can always edit the ranger shifts, but cannot edit the sanctuary or parking shifts", and then "designate control over signups to someone else" would be a secondary feature. So, I'd create internal groups in the VMS that handle this, but the lead is always in the group by default.

…

On Mon, Jun 19, 2017 at 1:51 PM, Patrick Boyd ***@***.***> wrote: So basically you can get titles from the user API (for users that have titles). It's an array because they can have multiple titles (like a CC member and an AF for example). You can also get what groups they are in. I use groups a bit more often in the current code (i.e. they are a lead). You can then use the title array to narrow it down more (i.e. they are the ranger lead). But I was thinking we might need either more groups (i.e. these users are authorized to edit the Ranger team's shifts and approve sign ups) rather than relying on the one lead to do that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYiYV0vrnGRiSZNfkyUB5tVCSr0WtY9bks5sFsMrgaJpZM4N-nKe> .

[Patrick Boyd]

Ok, so you think that titles would be good to add to the JWT or is that from the API acceptable? I don't think it's a common thing most apps are going to grab, so I'd like to stick to the API as the source of truth if possible.

[dahling-jerry]

Sticking to the API is fine by me.

…

On Mon, Jun 19, 2017 at 3:47 PM, Patrick Boyd ***@***.***> wrote: Ok, so you think that titles would be good to add to the JWT or is that from the API acceptable? I don't think it's a common thing most apps are going to grab, so I'd like to stick to the API as the source of truth if possible. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYiYV-0-k2ZGhw3LzLbG3zfBbTbjQPqLks5sFt5XgaJpZM4N-nKe> .