🎁 Adding WorkAuthorization model for CDL #647
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jeremyf
force-pushed
the
633-controlled-digital-lending
branch
6 times, most recently
from
c099405
to
13d35b5
Compare
With this commit, we're adding a mechanism to "lend" folks books. This change accounts for granting a user read rights to a work. It does not introduce the logic/functionality that "authorizes" or "revokes" this loaned resource. With this commit, there are no changed production logic paths. Related to: - #633 Co-authored-by: Summer Cook <[email protected]>
jeremyf
force-pushed
the
633-controlled-digital-lending
branch
from
13d35b5
to
98cc8aa
Compare
jeremyf
force-pushed
the
633-controlled-digital-lending
branch
from
220524d
to
68f644c
Compare
aprilrieger
approved these changes
Aug 7, 2023
1 task
jeremyf
added a commit
that referenced
this pull request
Aug 31, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Aug 31, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Aug 31, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Aug 31, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Aug 31, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Aug 31, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Aug 31, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Sep 5, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Sep 5, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Sep 5, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Sep 5, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Sep 5, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Sep 5, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Sep 5, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Sep 5, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Sep 5, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Sep 6, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). And once they login for the CDL asset, we redirect to that asset. Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Sep 13, 2023
We are trying to serve two types of users: - Admins - Not-admins Given that admins are a small subset, we can train and document how they can sign in. In other words, favor workflows that impact the less trained folk to help them accomplish their tasks. Prior to this commit, given the site had an SSO provider, when I (an unauthenticated user) went to a private work, then it would redirect me to the `/user/sign_in` route. At that route I had the following option: 1. Providing a username and password 2. Selecting one of the SSO providers to use for sign-in. The problem with this behavior was that a user who was given a Controlled Digital Lending (CDL) URL would see a username/password and likely attempt to authenticate with their CDL username/password (which was managed by the SSO provider). The end result is that the authentication page most likely would create confusion. With this commit, I'm setting things up such that when the application uses calls `new_user_session_path` we make a decision on what URL to resolve. Related to: - #766 - #647 - #633
jeremyf
added a commit
that referenced
this pull request
Sep 13, 2023
We are trying to serve two types of users: - Admins - Not-admins Given that admins are a small subset, we can train and document how they can sign in. In other words, favor workflows that impact the less trained folk to help them accomplish their tasks. Prior to this commit, given the site had an SSO provider, when I (an unauthenticated user) went to a private work, then it would redirect me to the `/user/sign_in` route. At that route I had the following option: 1. Providing a username and password 2. Selecting one of the SSO providers to use for sign-in. The problem with this behavior was that a user who was given a Controlled Digital Lending (CDL) URL would see a username/password and likely attempt to authenticate with their CDL username/password (which was managed by the SSO provider). The end result is that the authentication page most likely would create confusion. With this commit, I'm setting things up such that when the application uses calls `new_user_session_path` we make a decision on what URL to resolve. Related to: - #766 - #647 - #633
jeremyf
added a commit
that referenced
this pull request
Sep 13, 2023
We are trying to serve two types of users: - Admins - Not-admins Given that admins are a small subset, we can train and document how they can sign in. In other words, favor workflows that impact the less trained folk to help them accomplish their tasks. Prior to this commit, given the site had an SSO provider, when I (an unauthenticated user) went to a private work, then it would redirect me to the `/user/sign_in` route. At that route I had the following option: 1. Providing a username and password 2. Selecting one of the SSO providers to use for sign-in. The problem with this behavior was that a user who was given a Controlled Digital Lending (CDL) URL would see a username/password and likely attempt to authenticate with their CDL username/password (which was managed by the SSO provider). The end result is that the authentication page most likely would create confusion. With this commit, I'm setting things up such that when the application uses calls `new_user_session_path` we make a decision on what URL to resolve. Related to: - #766 - #647 - #633
jeremyf
added a commit
that referenced
this pull request
Sep 13, 2023
We are trying to serve two types of users: - Admins - Not-admins Given that admins are a small subset, we can train and document how they can sign in. In other words, favor workflows that impact the less trained folk to help them accomplish their tasks. Prior to this commit, given the site had an SSO provider, when I (an unauthenticated user) went to a private work, then it would redirect me to the `/user/sign_in` route. At that route I had the following option: 1. Providing a username and password 2. Selecting one of the SSO providers to use for sign-in. The problem with this behavior was that a user who was given a Controlled Digital Lending (CDL) URL would see a username/password and likely attempt to authenticate with their CDL username/password (which was managed by the SSO provider). The end result is that the authentication page most likely would create confusion. With this commit, I'm setting things up such that when the application uses calls `new_user_session_path` we make a decision on what URL to resolve. Related to: - #766 - #647 - #633
jeremyf
added a commit
that referenced
this pull request
Sep 13, 2023
We are trying to serve two types of users: - Admins - Not-admins Given that admins are a small subset, we can train and document how they can sign in. In other words, favor workflows that impact the less trained folk to help them accomplish their tasks. Prior to this commit, given the site had an SSO provider, when I (an unauthenticated user) went to a private work, then it would redirect me to the `/user/sign_in` route. At that route I had the following option: 1. Providing a username and password 2. Selecting one of the SSO providers to use for sign-in. The problem with this behavior was that a user who was given a Controlled Digital Lending (CDL) URL would see a username/password and likely attempt to authenticate with their CDL username/password (which was managed by the SSO provider). The end result is that the authentication page most likely would create confusion. With this commit, I'm setting things up such that when the application uses calls `new_user_session_path` we make a decision on what URL to resolve. Related to: - #766 - #647 - #633
jeremyf
added a commit
that referenced
this pull request
Sep 13, 2023
We are trying to serve two types of users: - Admins - Not-admins Given that admins are a small subset, we can train and document how they can sign in. In other words, favor workflows that impact the less trained folk to help them accomplish their tasks. Prior to this commit, given the site had an SSO provider, when I (an unauthenticated user) went to a private work, then it would redirect me to the `/user/sign_in` route. At that route I had the following option: 1. Providing a username and password 2. Selecting one of the SSO providers to use for sign-in. The problem with this behavior was that a user who was given a Controlled Digital Lending (CDL) URL would see a username/password and likely attempt to authenticate with their CDL username/password (which was managed by the SSO provider). The end result is that the authentication page most likely would create confusion. With this commit, I'm setting things up such that when the application uses calls `new_user_session_path` we make a decision on what URL to resolve. Related to: - #766 - #647 - #633
jeremyf
added a commit
that referenced
this pull request
Sep 13, 2023
We are trying to serve two types of users: - Admins - Not-admins Given that admins are a small subset, we can train and document how they can sign in. In other words, favor workflows that impact the less trained folk to help them accomplish their tasks. Prior to this commit, given the site had an SSO provider, when I (an unauthenticated user) went to a private work, then it would redirect me to the `/user/sign_in` route. At that route I had the following option: 1. Providing a username and password 2. Selecting one of the SSO providers to use for sign-in. The problem with this behavior was that a user who was given a Controlled Digital Lending (CDL) URL would see a username/password and likely attempt to authenticate with their CDL username/password (which was managed by the SSO provider). The end result is that the authentication page most likely would create confusion. With this commit, I'm setting things up such that when the application uses calls `new_user_session_path` we make a decision on what URL to resolve. Related to: - #766 - #647 - #633
jeremyf
added a commit
that referenced
this pull request
Sep 13, 2023
We are trying to serve two types of users: - Admins - Not-admins Given that admins are a small subset, we can train and document how they can sign in. In other words, favor workflows that impact the less trained folk to help them accomplish their tasks. Prior to this commit, given the site had an SSO provider, when I (an unauthenticated user) went to a private work, then it would redirect me to the `/user/sign_in` route. At that route I had the following option: 1. Providing a username and password 2. Selecting one of the SSO providers to use for sign-in. The problem with this behavior was that a user who was given a Controlled Digital Lending (CDL) URL would see a username/password and likely attempt to authenticate with their CDL username/password (which was managed by the SSO provider). The end result is that the authentication page most likely would create confusion. With this commit, I'm setting things up such that when the application uses calls `new_user_session_path` we make a decision on what URL to resolve. Related to: - #766 - #647 - #633
jeremyf
added a commit
that referenced
this pull request
Sep 13, 2023
Prior to this commit, we had not wired in the logic for authorization to controlled digital lending (CDL) assets. With this change, we're adding the logic for handling a user authenticating to access a work. The logic flow is as follows: An unauthenticated user goes to a CDL asset page. They are neither authorized nor authenticated, so we direct them to the new session route. There we capture we're the URL of the requested resource and send them on their way to authenticate. When we perform the handshake with OpenID, we provide (as scope and client design decision) the URL of the CDL asset. The OpenID provider authenticates and returns to the OmniAuth callback. We use the returned scope to then grant authorization to the CDL asset (and revoke any expired authorizations). And once they login for the CDL asset, we redirect to that asset. Related to: - #633 - #647
jeremyf
added a commit
that referenced
this pull request
Sep 13, 2023
We are trying to serve two types of users: - Admins - Not-admins Given that admins are a small subset, we can train and document how they can sign in. In other words, favor workflows that impact the less trained folk to help them accomplish their tasks. Prior to this commit, given the site had an SSO provider, when I (an unauthenticated user) went to a private work, then it would redirect me to the `/user/sign_in` route. At that route I had the following option: 1. Providing a username and password 2. Selecting one of the SSO providers to use for sign-in. The problem with this behavior was that a user who was given a Controlled Digital Lending (CDL) URL would see a username/password and likely attempt to authenticate with their CDL username/password (which was managed by the SSO provider). The end result is that the authentication page most likely would create confusion. With this commit, I'm setting things up such that when the application uses calls `new_user_session_path` we make a decision on what URL to resolve. Related to: - #766 - #647 - #633
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note: This is the "how do we give and revoke access" not the "when do I give and revoke"; that is something determined during user authentication and is partially dependent on the SSO work. However, this highlights the underlying logic to authorize and revoke user's read rights for given works.
🎁 Adding WorkAuthorization model for CDL
98cc8aa
With this commit, we're adding a mechanism to "lend" folks books. This
change accounts for granting a user read rights to a work.
It does not introduce the logic/functionality that "authorizes" or
"revokes" this loaned resource. With this commit, there are no changed
production logic paths.
Related to:
Co-authored-by: Summer Cook [email protected]
🎁 Adding logic for handling user signin
220524d
With this change, we're adding the logic for handling a user
authenticating:
authentication.
Related to: