Creating an API key, but it's already expired when trying to use it.

@dmoraBerlin It has been a long time since looking at this issue but it seems like the biggest topic is that the UI is using local time and the backend is using server time. In my opinion we should try to reflect this in the calendar picker or expiration date field. This person should not have had the option to expire a key "tomorrow" because in server time, it was already "tomorrow."

@m_gill @mroussin how'd do you feel about a simple helper text stating:

Time based off of server clock (currently 00:00 YYYY-MM-DD)

This would set expectation of what the time calculation would correctly be. This would also minimize any code conflict by having to create a new system to go between the two variables. @eduardosanz do you have any feedback from the front end perspective?

@dmoraBerlin If we were to place a header text saying it's 2022-06-10 and the calendar still shows 2022-06-09 as an option, I think we'd get another UX issue. It should be a simple time conversion between local and UTC and not necessarily a new system. Let's get @eduardosanz's thoughts - @eduardosanz would you also provide a weight based on whatever you propose?

@dmoraBerlin and @m_gill, I think the time difference between the user and the server should not be a concern to the user.

I confirm the token's created_at field is a 'timestamp' stored in the database in UTC. However, the expires_at is a 'date' (not a 'timestamp').

One solution could be to:

convert the expires_at data type to 'timestamp', and
for the frontend to convert the expiration date to a UTC time, when creating a new token.

Otherwise, I think we would need add a helper text informing the user about this limitation, which is unfortunate.

I am pinging the backend to get feedback: @dblessing, @ifarkas, @bdenkovych.

Depending on how we want to solve this issue we would weight it differently.

select column_name, data_type from information_schema.columns where table_name = 'personal_access_tokens';
             column_name             |          data_type
-------------------------------------+-----------------------------
 id                                  | integer
 user_id                             | integer
 name                                | character varying
 revoked                             | boolean
 expires_at                          | **date**
 created_at                          | **timestamp without time zone**
 updated_at                          | timestamp without time zone
 scopes                              | character varying
 impersonation                       | boolean
 token_digest                        | character varying
 expire_notification_delivered       | boolean
 last_used_at                        | timestamp with time zone
 after_expiry_notification_delivered | boolean
(13 rows)

@eduardosanz @m_gill I like the idea of converting the expiration to timestamp as Eduardo suggested. That would resolve the issue I believe.

Updating to use timestamp would also resolve this security issue. cc @jarka

That's a good point, thanks @eduardosanz @m_gill @dmoraBerlin. I am marking this issue related to the security one and will explain the reason on that issue.

added UX backend priority4 severity4 labels and removed priority2 severity2 labels

removed SLOMissed label

Setting label(s) ~"Category:Authentication and Authorization" based on ~"group::access".

added 1 deleted label

added workflowproblem validation label

added frontend label

added workflowplanning breakdown label and removed workflowproblem validation label

added candidate15.3 label

marked this issue as related to #36452 (closed)

changed milestone to %15.3

mentioned in issue gitlab-org/manage/general-discussion#17537

@hsutor I'm taking this out of planning because it will be solved by https://gitlab.com/gitlab-org/gitlab/-/issues/364526

changed milestone to %Backlog

mentioned in issue gitlab-org/manage/general-discussion#17550

removed candidate15.3 label

added Category:System Access label

added vintage label

Hi @mroussin ,

Thanks for raising this bug.

Contributions like this are vital to help make GitLab a better product.

We would be grateful for your help in verifying whether your bug report requires further attention from the team. If you think this bug still exists, and is reproducible with the latest stable version of GitLab, please comment on this issue.

This issue has been inactive for more than 12 months now and based on the policy for inactive bugs, will be closed in 7 days.

Thanks for your contributions to make GitLab better!

added stale label

Hi @mroussin ,

Based on the policy for inactive bugs, this issue is now being closed.

If you think this bug still exists, and is reproducible with the latest stable version of GitLab, please reopen this issue.

Thanks for your contributions to make GitLab better!

closed

added auto closed label

Creating an API key, but it's already expired when trying to use it.

Summary

Steps to reproduce

What is the current bug behavior?

What is the expected correct behavior?

Relevant logs and/or screenshots

Designs

Child items ...

Activity

Creating an API key, but it's already expired when trying to use it.

Summary

Steps to reproduce

What is the current bug behavior?

What is the expected correct behavior?

Relevant logs and/or screenshots

Relates to

Activity