You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Out of the box, the package is very silent whenever issues happen.
It's not trivial to set logging correctly (it's not with native Django, and it's even less with possible not clearly defined interference between the native django settings.LOGGING and settings.DEBUG and their counterparts in settings.SAML2_AUTH).
In my case, after trying for over one hour to get output, I got rid of the exception handler and then only got a nice and clear trace indicating the exact issue (which was Cannot find ['xmlsec1']). From the issue tracker, it seem many people struggle in a similar way with uninformative error messages (Sorry, you are not allowed to access this app).
What about completely removing the exception handler when Django's settings.DEBUG=True, so that we get regular debug information ? Arguably even so when DEBUG=False, as I don't see a good reason for this package to provide some custom exception handling ?
Thanks !
For reference, here's a dirty monkey-patch to disable the exception handler (in your settings.py):
# monkey-patch out django_saml2_auth's exception handler to get proper traces# https://github.com/grafana/django-saml2-auth/issues/275ifDEBUG:
importdjango_saml2_auth.utilsdjango_saml2_auth.utils.exception_handler=lambdafunc: func
The text was updated successfully, but these errors were encountered:
I think the root cause is correctly identified by @73VW in #277 and I fixed it in #281. I hope this help resolve the issue after I release a new version, which will happen very soon. In the meantime use the main branch to test the changes. I'd be happy to see this resolved.
I kind of have the same issue. Your monkepatch didn't work for me, but luckily functool.wraps is used so it's possible to call the undecorated function and add your own exception handling like this:
try:
# call the original acs view without the exception_handler decoratorresponse=saml_views.acs.__wrapped__.__wrapped__(request)
exceptExceptionasexc:
response=handle_exception(exc, request, config)
I would prefer if there was an proper undecorated acs function you can call and implement your own exception handling on top. I also think that the responses generated by the exception handler are often wrong. For example: If a client uses the wrong key to sign the assertions this will trigger an internal server error with status 500 despite pysaml2 throwing the right exception. It's really hard to convince people they need fix something after your web server confessed to them it made a mistake 😅.
Hi !
Out of the box, the package is very silent whenever issues happen.
It's not trivial to set logging correctly (it's not with native Django, and it's even less with possible not clearly defined interference between the native django
settings.LOGGING
andsettings.DEBUG
and their counterparts insettings.SAML2_AUTH
).In my case, after trying for over one hour to get output, I got rid of the exception handler and then only got a nice and clear trace indicating the exact issue (which was
Cannot find ['xmlsec1']
). From the issue tracker, it seem many people struggle in a similar way with uninformative error messages (Sorry, you are not allowed to access this app
).What about completely removing the exception handler when Django's
settings.DEBUG=True
, so that we get regular debug information ? Arguably even so whenDEBUG=False
, as I don't see a good reason for this package to provide some custom exception handling ?Thanks !
For reference, here's a dirty monkey-patch to disable the exception handler (in your settings.py):
The text was updated successfully, but these errors were encountered: