I tried the patch in
https://www.drupal.org/project/drupal/issues/2794431
🌱
[META] Formalize translations support
Needs work
, i took it from the open merge request.
But its unfortunately this seems not working.
erwandsn → created an issue.
Reroll it for the current 6.2.3 Webform version
And for your first question,
The website in case is really a simple website. Displaying static data and no more.
In my opinion the SSO is the more complex functionnality at it, so i think there is nothing in interaction with "is_cas_user" and "cas_username" session data.
When monitoring ressources during a SSO user page loading, the process CPU progressivly raise to 100% and fall down to < 1% after serving the page. Really look like something is looping in the process, in combination of this Bug is coming after D10 migration, thats why accessCheck() trouble is my guess.
_core:
default_config_hash: 2z_THKqotLn7-Fl5rKmZkNmZph-IVfv-8q1ShRZAqBY
login_link_enabled: false
login_link_label: 'CAS Login'
login_success_message: 'You have been logged in.'
server:
version: '3.0'
protocol: https
hostname: sso.xxxxx
port: 443
path: ''
verify: 0
cert: ''
gateway:
enabled: false
recheck_time: -1
paths:
id: request_path
negate: false
pages: ''
method: server_side
forced_login:
enabled: false
paths:
id: request_path
negate: false
pages: ''
user_accounts:
prevent_normal_login: true
auto_register: true
email_assignment_strategy: 1
email_hostname: ems.post
email_attribute: email
auto_assigned_roles: { }
restrict_password_management: false
restrict_email_management: false
error_handling:
login_failure_page: ''
message_validation_failure: 'There was a problem logging in, please contact a site administrator.'
message_no_local_account: 'There was a problem logging in, please contact a site administrator.'
message_subscriber_denied_reg: 'There was a problem logging in, please contact a site administrator.'
message_subscriber_denied_login: 'There was a problem logging in, please contact a site administrator.'
message_account_blocked: 'There was a problem logging in, please contact a site administrator.'
message_username_already_exists: 'There was a problem logging in, please contact a site administrator.'
message_prevent_normal_login: 'This account must log in using CAS.'
message_restrict_password_management: 'The requested account is associated with CAS and its password cannot be managed from this website.'
logout:
cas_logout: true
logout_destination: ''
enable_single_logout: false
single_logout_session_lifetime: 25
proxy:
initialize: false
can_be_proxied: false
proxy_chains: ''
advanced:
debug_log: false
connection_timeout: 10
We are using https://www.drupal.org/project/entity_access_by_role_field → (which is doing a lot access check to manage permission on each node).
User logged throught SSO:
Without entity_access_by_role_field module, loading a Page is taking +- 12s (it was < 12s before D10 migration) for a User logged as SSO, after activation of restrict_access module it raise to 27s for this same User.
User logged normaly
Whithout entity_access_by_role_field (1.52s loading)
Whith entity_access_by_role_field (1.75s loading)
Im opening back this issue.
It appears that since Drupal 10 add mandatory ->accessCheck() on entityQueries usage, it seems their is a conflict with CAS Server.
Every accessCheck added on a page is adding signitificative page loading time when the user is connected by SSO.
It really seems like SSO queries are done on every accessCheck triggerd to load a certain page.
In my case when the page is cached, their is no problem. But i have site using a cache per User so that really annoying.
Does the SSO queries plug on the accessCheck process ?
Thanks in advance for you investigations.
I finally found that the original site builder used a dumb module, wich is responsible of this error.
I close this issue since its not a CAS related problem.
Ps: but i dont understand why SSO user only are affected in my case.
Update: i think i find a good way to explore, it might have a conflict in code With access Check. Wich is in phase with Drupal 10.
Stay tuned for more
If i uninstall the SSO it will work (as its forking for a standard account).
Does something related to CAS SSO is done at every requests ?
I agree with you, i don't understand the source of the error.
And yes if im anonymous / logged in with a Drupal original account there is absolutly no probleme.
Only if im logged with a SSO User, and after logged in every page the user is loading take 10 secs to respond.
erwandsn → created an issue.
erwandsn → created an issue.
erwandsn → created an issue.