Closed Bug 988845 Opened 10 years ago Closed 10 years ago

Generating a call-url should allow a "duration" parameter.

Categories

(Hello (Loop) :: Server, defect)

Product:
Hello (Loop)
Component:
Server
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: alexis+bugs, Unassigned)

References

Details

(Whiteboard: [qa+]) 

We should allow the users to specify how long a token is valid for.
Where's the requirement for this come from? This choice would seem to be unnecessarily complex from a user's point of view.

Also, I don't see this blocking MLP.
This is important to be able to know for how long we want to store token revocation.

For MLP on client side we can use the default value of one month but to keep database integrity, we need to be carefull of the storing time of each record.
Why doesn't the server control this for now, until there's a clear user requirement?
Let me clarify this: this is optional on the client. You don't *need* to specify the option, but if you do it should be taken in consideration.
https://github.com/mozilla-services/loop-server/commit/64b02b07a0e594c57f39d431893c30c72b36768d
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Depends on: 1012576
Is there any UI hooked up to test this? I can't seem to find any in the desktop client.
Flags: needinfo?(alexis+bugs)
I think  there would only be a UI requirement in the client chooses to expose this. As of right now, it lives on the server, only, which means it could be configured on the server, as needed.
(In reply to James Bonacci [:jbonacci] from comment #7)
> I think  there would only be a UI requirement in the client chooses to
> expose this. As of right now, it lives on the server, only, which means it
> could be configured on the server, as needed.

Any chance that could be done as a one-off to test this is working correctly? or is this sufficiently covered with automation?
Flags: needinfo?(alexis+bugs)
If it stays on server, it is sufficiently covered with the unit testing:
loop-server/test/functional_test.js

So, yea, we could mess with it a bit on the server side if we wanted (especially on the Stage environment).
Whiteboard: [qa+]
Okay, assuming verified fixed based on unit tests. We'll want to retest this manually if we every decide to implement this in the client though.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.