Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[defect]: Date parsing fails when using Redis cache #5304

Open
GabrielMajeri opened this issue Mar 11, 2024 · 3 comments
Open

[defect]: Date parsing fails when using Redis cache #5304

GabrielMajeri opened this issue Mar 11, 2024 · 3 comments
Labels
defect category: a defect or misbehaviour

Comments

@GabrielMajeri
Copy link

GabrielMajeri commented Mar 11, 2024

What type of defect/bug is this?

Unexpected behaviour (obvious or verified by project member)

How can the issue be reproduced?

I've successfully configured the freeradius-oauth2-perl module module for authenticating with Microsoft Azure AD. Now I'm trying to get it to use Redis for cache, instead of the non-persistent in-memory cache.

I've enabled the redis module and configured it and I've also updated the freeradius-oauth2-perl/module file:

cache oauth2_cache {
    # ...
 
	# Use Redis instead of `rlm_cache_rbtree`
	driver = "rlm_cache_redis"

	# Connect to Redis container
	redis {
		server = 'redis-node-0'
		port = 6379
		query_timeout = 5
		pool = redis
}

The first time I use radtest to authenticate, it works, and it creates a new cache entry in Redis:

(0) oauth2_cache: No cache entry found for "[email protected]"
(0) oauth2_cache: Creating new cache entry
(0) oauth2_cache:   &request:OAuth2-Password-Last-Modified := &control:OAuth2-Password-Last-Modified -> Feb 18 2024 09:35:31 UTC
(0) oauth2_cache:   &control:Password-With-Header := &control:Password-With-Header -> '{ssha512}a0c7e7b2ef84ed2d19172b41 [truncated]'
(0) oauth2_cache: Merging cache entry into request

The cache entry (read directly from redis-cli) looks as follows:

"&Cache-Expires = 1711011923\n&Cache-Created = 1710147923\n&control:Password-With-Header := '{ssha512}a0c7... long hash here...'\n&OAuth2-Password-Last-Modified := Feb 18 2024 09:35:31 UTC\n"

However, subsequent requests fail to access the cache:

(1) oauth2_cache: EXPAND %{User-Name}
(1) oauth2_cache:    --> [email protected]
rlm_redis (redis): Reserved connection (0)
(1) oauth2_cache: ERROR: failed to parse time string "Feb"
rlm_redis (redis): Released connection (0)
(1)           [oauth2_cache] = fail

The issue seems to be with reading back the cached date, which FreeRADIUS created in the first place. I'm guessing this issue is similar to #3602, but I haven't been able to determine why it's happening.

@GabrielMajeri GabrielMajeri added the defect category: a defect or misbehaviour label Mar 11, 2024
@alandekok
Copy link
Member

On quick examination, it looks like the date is being saved as a string without spaces, but the parser seems to be expecting that the date is in quotation marks. The solution is likely to either print the full date string with spaces, or instead just print it as an integer.

@alandekok
Copy link
Member

Also, which version of FreeRADIUS are you running?

@GabrielMajeri
Copy link
Author

it looks like the date is being saved as a string without spaces, but the parser seems to be expecting that the date is in quotation marks

You're right! I've tried changing the dictionary for the freeradius-oauth2-perl module to this:

ATTRIBUTE	OAuth2-Password-Last-Modified	3000	string   # instead of date

and then adding quotes around the attribute:

&request:OAuth2-Password-Last-Modified := "%{&control:OAuth2-Password-Last-Modified}"

Afterwards I've restarted everything and tested that it works correctly.

Should I report this to the freeradius-oauth2-perl module, or is this an issue with the way the FreeRADIUS core treats serialization of dates in caches?

Also, which version of FreeRADIUS are you running?

The latest stable one from Dockerhub, i.e. FreeRADIUS version 3.2.3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
defect category: a defect or misbehaviour
Projects
None yet
Development

No branches or pull requests

2 participants