Uploaded image for project: 'Blesta Core'
  1. Blesta Core
  2. CORE-5206

Password reset date_expires not properly interpreted

    Details

      Description

      When a password reset form is filled out, a record is added to password_resets table. password_resets.date_expires seems to be timezone+Blesta.reset_password_ttl (from config/blesta.php and timezone from Settings > General > Localization). Shouldn't this be UTC?

      However, it appears that the link is already expired when generated, depending on the timezone set under Settings > System > Localization. So, the TTL is actually longer for some, and expired for others.

      To reproduce, set the timezone to UTC-7 (Los Angeles), generate a password reset. Note that the time stored in password_resets.date_expires is Los Angeles time + 4 hours, which is in the past if evaluated in UTC time.

      I think the date_expires is set in local timezone, and evaluated in UTC. Rather, we should set it and evaluate it in UTC.

        Activity

        admin Paul Phillips created issue -
        admin Paul Phillips made changes -
        Field Original Value New Value
        Rank Ranked higher
        admin Paul Phillips made changes -
        Description When a password reset form is filled out, a record is added to password_resets table. password_resets.date_expires seems to be timezone+Blesta.reset_password_ttl (from config/blesta.php and timezone from Settings > General > Localization). Shouldn't this be UTC?

        However, it appears that the link is already expired when generated, depending on the timezone set under Settings > System > Localization. So, the TTL is actually longer for some, and expired for others.

        To reproduce, set the timezone to UTC-8 (Los Angeles), generate a password reset. Note that the time stored in password_resets.date_expires is Los Angeles time + 4 hours, which is in the past if evaluated in UTC time.

        I think the date_expires is set in local timezone, and evaluated in UTC. Rather, we should set it and evaluate it in UTC.
        When a password reset form is filled out, a record is added to password_resets table. password_resets.date_expires seems to be timezone+Blesta.reset_password_ttl (from config/blesta.php and timezone from Settings > General > Localization). Shouldn't this be UTC?

        However, it appears that the link is already expired when generated, depending on the timezone set under Settings > System > Localization. So, the TTL is actually longer for some, and expired for others.

        To reproduce, set the timezone to UTC-7 (Los Angeles), generate a password reset. Note that the time stored in password_resets.date_expires is Los Angeles time + 4 hours, which is in the past if evaluated in UTC time.

        I think the date_expires is set in local timezone, and evaluated in UTC. Rather, we should set it and evaluate it in UTC.
        jonathan Jonathan Reissmueller made changes -
        Sprint 5.11.0 Sprint 1 [ 201 ]
        jonathan Jonathan Reissmueller made changes -
        Rank Ranked higher
        abdy Abdy Franco made changes -
        Assignee Abdy Franco [ abdy ]
        abdy Abdy Franco made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        abdy Abdy Franco made changes -
        Remaining Estimate 0 minutes [ 0 ]
        Time Spent 12 minutes [ 720 ]
        Worklog Id 17130 [ 17130 ]
        abdy Abdy Franco made changes -
        Time Spent 12 minutes [ 720 ] 4 hours, 28 minutes [ 16080 ]
        Worklog Id 17131 [ 17131 ]
        abdy Abdy Franco made changes -
        Status In Progress [ 3 ] In Review [ 5 ]
        Resolution Fixed [ 1 ]
        abdy Abdy Franco made changes -
        Time Spent 4 hours, 28 minutes [ 16080 ] 4 hours, 42 minutes [ 16920 ]
        Worklog Id 17137 [ 17137 ]
        jonathan Jonathan Reissmueller made changes -
        Status In Review [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            abdy Abdy Franco
            Reporter:
            admin Paul Phillips
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Fix Release Date:
              26/Jun/24

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 4 hours, 42 minutes
              4h 42m

                Agile