providers:
primary:
url: 'https://login.microsoftonline.com/<tenant-id>/v2.0'
client_id: '<your-client-id>'
client_secret: '<your-client-secret>'
send_oidc_logout: false
enable_refresh_token_use: true
server_cert: false
set_groups_from_attributes: false
scopes:
- 'openid'
- 'profile'
- 'email'
user_matching_source: 'oidc-email' #i tried oidc-username also
auto_create_atom_user: true
set_groups_from_attributes: false
redirect_url: 'site/index.php/oidc/login'
logout_redirect_url: 'site'
prod:
storage:
class: QubitCacheSessionStorage
param:
session_name: symfony
session_cookie_httponly: true
session_cookie_secure: true
cache:
class: sfMemcacheCache
param:
host: memcached
port: 11211
prefix: atom
storeCacheInfo: true
persistent: true
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ica-atom-users/44c5e435-ba67-46bb-98bc-924144028415n%40googlegroups.com.
Hi Alberto
Since it redirects to the homepage (not to `admin/secure`), your `authenticate()` is almost certainly succeeding and `signIn()` is running - the login is being lost on the *next* request, which points at the session not persisting rather than at the OIDC config. The OIDC state/nonce also live in the session, so everything hinges on memcache round-tripping correctly. A few things to try, in order:
1. Isolate memcache first (best single test)
Temporarily switch your session storage in `config/factories.yml` from `QubitCacheSessionStorage` back to the default file-based `QubitSessionStorage`, clear the cache (`php symfony cc`), restart php-fpm, and retry the OIDC login. If the login now sticks, the OIDC plugin is fine and the problem is your memcache session layer.
yaml
prod:
storage:
class: QubitSessionStorage
param:
session_name: symfony
session_cookie_httponly: true
session_cookie_secure: true
2. Check the memcache extension and connectivity
‘sfMemcacheCache’ uses the *legacy* `Memcache` class, not `Memcached`. Confirm on the php-fpm host:
php -r 'var_dump(class_exists("Memcache"));' # must be true
Critically, `Memcache::addServer()` returns success even when the host is unreachable, so writes can fail silently. Verify php-fpm can actually reach the `memcached` host and that items are being stored across a login attempt:
printf "stats\r\n" | nc memcached 11211 # watch curr_items / cmd_set climb
If php-fpm cannot resolve or reach `memcached`, sessions never persist even though the rest of the site appears to work.
3. Watch the log during the callback
`oidcUser` logs `OIDC exception: ...` on a state/nonce mismatch. Tail your qubit/php-fpm log while logging in:
- If you see that exception, the session is being lost “before” the callback (cookie or memcache round-trip).
- If you see no exception and a sign-in, it is lost “after” sign-in (session regeneration not written to memcache) - which matches your homepage symptom.
4. Proxy / HTTPS
`QubitCacheSessionStorage` drops the secure cookie flag when it thinks the request is not HTTPS. If you terminate TLS at a reverse proxy, make sure AtoM sees HTTPS (trust `X-Forwarded-Proto`) so the session cookie and the generated redirect_uri stay consistent.
5. Confirm the `email` claim is present
With `user_matching_source: oidc-email`, Entra ID often does not emit an `email` claim unless the user has a mail attribute or you add it as an optional claim in the app registration. Worth verifying, though given you reach the homepage the match is probably working.
My money is on #1 / #2 - a silent memcache write failure. Start there.
Groete / Regards
Johan Pieterse
082 337-1406
To view this discussion visit https://groups.google.com/d/msgid/ica-atom-users/bcabcc4a-42d0-4977-8e45-6da32dd44f45n%40googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ica-atom-users/bcabcc4a-42d0-4977-8e45-6da32dd44f45n%40googlegroups.com.