Cookie based authentication not possible with HTTPS

[eroji]

I've tried to fix this a number of times tweaking by Apache config, but just cannot get it to work. I see another ticket was opened with the same issue but was closed with the direction to remove the thruk_cookie_auth_vhost.conf file. While this does offer a workaround, it remove the ability to have the login form and session cookie. So is this still a to-do item or is there no plan to get this working for HTTPS?

The current problem is the following error when attempting to enable HTTPS and navigate to the home URL of Thruk

Error
Last Updated: Thu Dec 1 16:36:18 PST 2016
Thruk 2.12 - www.thruk.org
Logged in as ?

You are not authorized.
It seems like you are not authorized.

[sni]

It should just work (tm). Thruk just reads the session id from the cookie. You could check if the cookie seems valid with firebug or something like that. Besides that, Thruk just takes the REMOTE_ENV from the apache env.
You could also export THRUK_COOKIE_AUTH_VERBOSE in your ~/.thruk file. This should print more information in the apache error log.
Last but not least, the omd-labs comes with nagios/icinga/naemon and thruk with ssl already enabled and just works: https://labs.consol.de/omd/

[eroji]

So I turned on debug level logging and this is what I see. Doesn't seem very helpful. It seems like it should bring up the login form but instead it defaults to the state that the user is not authenticated if it's accessed via HTTPS.

[2016/12/06 11:24:48][blah.blah.blah][DEBUG][Thruk] logging initialized
[2016/12/06 11:24:48][blah.blah.blah][DEBUG][Thruk] https://blah.blah.blah/thruk/
[2016/12/06 11:24:48][blah.blah.blah][DEBUG][Thruk] $VAR1 = {};
[2016/12/06 11:24:48][blah.blah.blah][DEBUG][Thruk] checking auth
[2016/12/06 11:24:48][blah.blah.blah][DEBUG][Thruk] user not authenticated yet
[2016/12/06 11:24:48][blah.blah.blah][DEBUG][Thruk] user is not authenticated
[2016/12/06 11:24:48][blah.blah.blah][DEBUG][Thruk] You are not authorized.
[2016/12/06 11:24:48][blah.blah.blah][DEBUG][Thruk] on page: https://blah.blah.blah/thruk/
[2016/12/06 11:24:48][blah.blah.blah][INFO][Thruk]  3456 Req: 001   mem:  28.99 MB   1.67 MB   dur: 0.021s      ----   size:    5.965 kb   stat: 403   url: /thruk/
[2016/12/06 11:24:48][blah.blah.blah][DEBUG][Thruk] Profile:
+----------------------------------------------------------------------------------+-------------+
| _dispatcher: https://blah.blah.blah/thruk/                                       |    0.02060s |
|   Root begin                                                                     |   ~0.01997s |
|     Utils::read_cgi_cfg()                                                        |    0.00002s |
|     AddDefaults::add_defaults                                                    |   ~0.01911s |
|       Root end                                                                   |    0.00005s |
|       render_tt: error.tt                                                        |    0.01598s |
|         render: error.tt                                                         |    0.01588s |
|       _after_dispatch                                                            |    0.00014s |
+----------------------------------------------------------------------------------+-------------+

[sni]

The interesting information is in the apache logs. Also you can increase the rewrite log debug level.

[eroji]

Not sure if I did it correctly, but this is what I saw, in the Apache error_log (not ssl_error_log where I had expected)

TT error.tt:
cnt percent clk   user    sys  cuser   csys template
  1    50 %   0   0.01   0.00   0.00   0.00 _footer.tt
  1    49 %   0   0.01   0.00   0.00   0.00 _common_js_files.tt
  1     0 %   0   0.00   0.00   0.00   0.00 _common_css.tt
  1     0 %   0   0.00   0.00   0.00   0.00 _header_initial_states.tt
  1     0 %   0   0.00   0.00   0.00   0.00 extra_headers.tt
  1     0 %   0   0.00   0.00   0.00   0.00 _header_sites.tt
  1     0 %   0   0.00   0.00   0.00   0.00 _infobox.tt
  1     0 %   0   0.00   0.00   0.00   0.00 _common_js_bugs.tt
  1     0 %   0   0.00   0.00   0.00   0.00 _header.tt
  1     0 %   0   0.00   0.00   0.00   0.00 _common_js.tt
  1     0 %   0   0.00   0.00   0.00   0.00 error.tt
TT error.tt:
cnt percent clk   user    sys  cuser   csys template
  1     0 %   0   0.00   0.00   0.00   0.00 _common_css.tt
  1     0 %   0   0.00   0.00   0.00   0.00 _header_initial_states.tt
  1     0 %   0   0.00   0.00   0.00   0.00 _header_sites.tt
  1     0 %   0   0.00   0.00   0.00   0.00 ext

[sni]

Thats information from the Thruk cgis. The thruk_auth debug output is prefixed with thruk_auth: and should be in the apache error log.

[briancamp]

I've run into the same issue when using https and cookie auth on Centos 7.3. The login page displays and works properly when using http, but when using https I get the "It seems like you are not authorized." error immediately.

Nothing gets logged in Apache's error log at the time. Any suggestions?

Thanks

[cfeller]

I've got the same setup/issue as you @briancamp. I'm not sure why this issue was closed...

The workaround for me was to disable cookie authentication:

https://www.thruk.org/documentation/faq.html#how-can-i-disable-cookie-authentication

At that point you can implement authentication through Apache itself like you did in Thruk 1.x. This is what we're doing as a workaround, and it works fine.

[riskersen]

Hi,

the issue still persists.

So, the workaround is to disable cookie auth?

Regards
Oliver

[sni]

Is it still the issue from the first post? Did you follow this guide?
https://thruk.org/documentation/faq.html#enable-https-tls-ssl-in-apache-webserver-for-thruk

[savv3]

Is it still the issue from the first post? Did you follow this guide?
https://thruk.org/documentation/faq.html#enable-https-tls-ssl-in-apache-webserver-for-thruk

I didn't have this set, and it solved it for me.