OidcUserInfo builder shoud accept Instant for the updateAt method
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- java
- Domain
- authentication
Research direction
Start from the updatedAt method on the OidcUserInfo builder, which currently takes a String, and see how the updated_at claim is stored. Add an overload that takes an Instant and stores it as epoch seconds, which the spec requires as a JSON number, and check the existing claim("updated_at", ...) workaround in the issue for the expected output. Done means a test builds the user info from an Instant and asserts the updated_at claim is the matching Unix timestamp.
Written by the indexing model from the issue text.
Description
Describe the bug
This is the definition of the updated_at claim from the spec:
Time the End-User's information was last updated. Its value is a JSON number representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time.
Currently the updatedAt builder method accepts a String. The rendered claim in this case violates the spec.
To Reproduce
var info = OidcUserInfo.builder()
.updatedAt( "not a valid date")
.build();
Expected behavior
The method should accept an Instant object and render as the unix timestamp corresponding to the value.
For now, the workaround is to use claim("updated_at", Instant.now().getEphochSecond())
- Dominant language
- Java
- Stars
- 9.7k
- Forks
- 6.4k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 42
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from spring-projects/spring-security
-
status: waiting-for-triage
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
spring-projects/spring-security#19996 ·
Maintainers usually reply within 1 day
-
status: waiting-for-triage type: enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
spring-projects/spring-security#19995 ·
Maintainers usually reply within 1 day
-
status: waiting-for-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
spring-projects/spring-security#19984 ·
Maintainers usually reply within 1 day
-
Spring-security-7.1.xsd schema validates request-matcher incorrectlyPossibly taken @suryakant-source claimed this 10 days ago. Openstatus: waiting-for-triage type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
spring-projects/spring-security#19981 · 1 comment ·
Maintainers usually reply within 1 day
-
status: waiting-for-triage
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
spring-projects/spring-security#19963 ·
Maintainers usually reply within 1 day
All issues in spring-projects/spring-security
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
liberation-data/drivine4j#547 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
BindingServiceProperties.bindings regressed to a non-thread-safe TreeMap in GH-3158: concurrent first use of binding names corrupts itPossibly taken @AkashB23 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
spring-cloud/spring-cloud-stream#3321 ·
Maintainers usually reply within 1 day
-
[Bug] 资源包列表 与 模组/数据包/世界 列表排列顺序不一致Possibly taken @fishdry1000 claimed this 4 days ago. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
ai-driven-fuzzing bug claude Minor
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
linagora/twake-calendar-side-service#1333 ·
Maintainers usually reply within 1 day