Hello Mike, Ok well noted.
What about my assumptions related to # in URL ? Even recognized by Guacamole, if tomcat or Apache in front dont relay it, this will not be received/used by Guacamole. The fact remains, if this can help, Guacamole works greatly via Apache OIDC auth then Guacamole auth-header. Barring the appropriate headers on Apache, I failed bypassing OIDC control until now... Brgrds > On Tue, Dec 4, 2018 at 11:59 PM B3r3n <[email protected]> wrote: > >> ... >> > ... >> >> I am puzzled with the fact Guacamole claims the >> >> user-mapping.xml file, as well as the fact it >> >> bound the fileauth provider. To me that is useless since openid is >> hereââ¬Â¦ >> >> >> > >> > The "user-mapping.xml" authentication mechanism is built into Guacamole. >> It >> is always loaded but is loaded last. If any extensions are present at all, they will take priority, with "user-mapping.xml" finally getting a crack at authentication after all other extensions have had a chance. If you do not have a "user-mapping.xml" file at all, then this will have no effect. Ok, IMHO this remains puzzling. When you dont use something, why complaining >> you cant get it. If there is no use of fileauthprovider & user-mapping >> because >> other modules will do the job, complaining puzzles... Just my opinion... >> > > The message that "user-mapping.xml" does not exist and thus will not be read is logged at the debug level. You can expect that and many other potentially-confusing status messages, stack traces, etc. to be logged at the debug level. They are there to establish context and inform you (or developers) of what is happening internally. You can expect debug-level messages to be low-level and to contain information that may only be useful to those already familiar with the internals of Guacamole. > > - Mike > > >
