View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0021673 | mantisbt | administration | public | 2016-09-07 23:47 | 2016-11-27 00:45 |
Reporter | vboctor | Assigned To | vboctor | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.3.1 | ||||
Target Version | 1.3.4 | Fixed in Version | 1.3.4 | ||
Summary | 0021673: Extend activation URL validity period from 1 to 7 days | ||||
Description | At the moment when a user is created and receives an account activation URL that expires within 24 hours. Often the receives sees it or takes action on it after 24 hours due to time zones or weekends or other reasons. In such case, the URL is invalid and the whole cycle has to be repeated. The same applies for lost password or reset password actions. These links should expire in 30 days. There is really no rush to expire them in 24 hours. 30 days will cover even the cases when someone is on vacation and comes up and accepts the invite. | ||||
Tags | mantishub | ||||
What about having different validity periods for the different use cases? lost password: 1 hour, the user triggers the action himself and is waiting for instant email user creation by signup: 1 hour, the user triggers the action himself and is waiting for instant email reset password: 3 days, the user asks the admin to reset the password, but does not know when the admin will react, 3 days should be enough to cover time zones and weekend aspects user creation by the administrator: 30 days should be enough to cover vacation aspect Maybe add 1 hour (or use configuration option for it) if email is sent by cron job. |
|
@atrol I'm not sure why we will add the complexity of having N different threshold. This just causes confusion when users miss the window. I don't see why we don't have a relaxed deadline. Reasons are:
Hence, I would go with a single threshold of 30 days and call it a day. Simple, works, and not really an issue in my opinion. So fix will be as follows: Replace: With: |
|
when creating the constant, i didn't have a strong reason to set it to 24 hours over any other time frame. @atrol So, other than some imposed compliance, policies, etc i would not go for complicating the logic for different times. |
|
@cproensa |
|
I was thinking on the self-service scenario, where the user requests the activation through the "lost password" form, for defining at 24 hours.
if there is no security risk for going from 1 to 30 days, then technically yes, expiration could be any arbitrary date. As i said, i can think that a requirement for a different value may come from imposed policies, so this could be left as a (global) config option. |
|
Even if the likelihood of it to happen is quite low, there is a risk that the message is intercepted or the link forged, which could give someone undue access to someone else's account. While I agree that 24 hours is probably too short in some cases, going for 30 days seems a bit too extreme, and I would propose a shorter delay, say 3 days but no more than 1 week. I also don't see the reason for differentiated deadlines. |
|
I think of the duration as a way for us to cleanup abandoned invitations rather than a security feature. The interception scenario applies equally to a 1 day duration as it applies to 3 day, 1 week, or 1 month. I'm OK with a 7 day or 30 days, but nothing less than 7 days. I also don't see a reason for multiple durations. I'm OK with a constant N days or a config option that is defaulted to the threshold we see as reasonable (7 or 30) days. |
|