+1
David
On Wed, Dec 13, 2017 at 11:36 AM, Brian Bouterse
wrote:
> +1 to this
>
>
> On Wed, Dec 13, 2017 at 10:03 AM, Daniel Alley wrote:
>
>> - close issues 3163 and 3164
>>> - move JWT auth use cases from the MVP document[2] to the 3.1+
>>>
+1 to this
On Wed, Dec 13, 2017 at 10:03 AM, Daniel Alley wrote:
> - close issues 3163 and 3164
>> - move JWT auth use cases from the MVP document[2] to the 3.1+
>> document[3].
>> - add a story for removing "djangorestframework-jwt" from pulp 3.0
>
>
> s/story/task, and
>
+1 to just those use cases. Since we can rollback the change I updated the
MVP with this change:
https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viable_Product/diff?utf8=%E2%9C%93=125_from=124=View+differences
I also added an explicit use case saying that basic auth can authenticate
to all
On Fri, Dec 1, 2017 at 2:47 PM, David Davis wrote:
> I would just do:
>
> As a JWT authenticated user, I can refresh my JWT token if Pulp is
> configured with JWT_ALLOW_REFRESH set to True (default is False).
>
> Having two user stories means two separate items in redmine,
I would just do:
As a JWT authenticated user, I can refresh my JWT token if Pulp is
configured with JWT_ALLOW_REFRESH set to True (default is False).
Having two user stories means two separate items in redmine, and both of
these user stories will probably be fixed in one commit/PR.
David
On
Your proposal is basically what we have today (except it’s called
JWT_ALLOW_REFRESH in django-rest-framework-jwt rather than JWT_REFRESH).
You can configure settings for django-rest-framework-jwt from the
server.yaml file [0] so users can turn on/off JWT_ALLOW_REFRESH. It
defaults to False.
The
I think @misa's point is that if a valid token becomes compromised, it
could be renewed for a long-maybe-forever time.
I'm reading a desire to have Pulp exhibit both of these types of behaviors,
and both for good reasons. What if we introduce a setting JWT_REFRESH. If
enabled, JWT_REFRESH will
Good points.
> Another scenario: someone tcpdumps my traffic (yes, somehow they have the
SSL cert, work with this assumption for now). They can come back 3 days
from now, browse the tcpdump output, and renew the token. That would not be
possible with a short-lived token and no renewal past
>
> Jeremy, I don't think I understand your comment.
>
> You *will* have to use basic auth to refresh the token when the original
> one expires.
>
Right. I understand that. I'm not arguing that we allow the user to
generate a valid JWT token using an expired, invalid JWT token. I'm arguing
that
+1. I think one should be able to get a JWT with a JWT. This user
experience:
> I can authenticate any API call with a JWT token.
...is nicer than this user experience:
> I can authenticate any API call with a JWT token. Oh, wait, exept getting
a new JWT token. I wonder why? Is there some
+1
On 11/28/2017 04:34 PM, Dennis Kliban wrote:
> Our MVP doc currently states "As an API user, I can authenticate any API call
> (except to request a JWT) with a
> JWT. (not certain if this should be the behavior) [in progress]"
>
> The uncertainty was due to the "except to request a JWT"
On Tue, Nov 28, 2017 at 8:32 PM, David Davis wrote:
> I’m not sure I fully understand this last paragraph about setting a
> maximum amount of time per token. Regardless, I would not add the ability
> to request new JWT tokens using JWT authentication in the MVP unless it’s
I’m not sure I fully understand this last paragraph about setting a maximum
amount of time per token. Regardless, I would not add the ability to
request new JWT tokens using JWT authentication in the MVP unless it’s easy
to implement. I think we want that eventually but what we have today
supports
Our MVP doc currently states "As an API user, I can authenticate any API
call (except to request a JWT) with a JWT. (not certain if this should be
the behavior) [in progress]"
The uncertainty was due to the "except to request a JWT" clause.
I propose that Pulp 3 should support requesting a new
14 matches
Mail list logo