Comment 1 Dirk Wiesenthal 2019-12-20 17:20:37 CET

Seems to be a mere typo in the session handling. Apparently, the password attribute is named "_password". In my tests, it worked.

Comment 2 Dirk Wiesenthal 2019-12-20 17:22:35 CET

(Accidentally committed the fix below Bug #50498)

Comment 3 Florian Best 2019-12-20 21:33:13 CET

The change looks useless as Base.password is a @property which sets self._password.
If this really works, please describe why.

Comment 4 Dirk Wiesenthal 2019-12-21 02:27:14 CET

Right. It worked in our tests. We stopped the module process and somehow the very first tools.umcpCommand did not show the password dialog (although this very bug states it should have). So we thought we fixed it. But it looks like it downgraded to SAML right after the initialization. So the second call already wanted the new password.

Anyway, I think I got it right now.

In protocol/session.py, there is a comment

# only set the credentials in 1. a new session 2. if password changed or 3. if logged in via plain authentication

But the if clause uses
if ... or result.credentials['auth_type']:
  # reset credentials to what we get from umc-web-server (?)

Unfortunately, "result.credentials['auth_type']" is the opposite of "3. if logged in via plain authentication". (It is None in this case)

So I changed it to "if ... is None"

Comment 5 Florian Best 2019-12-21 09:12:23 CET

Okay, this looks better.

Comment 6 Jannik Ahlers 2020-01-08 10:52:52 CET

Code: OK
YAML: OK
Fix: OK
-> Verified

Comment 7 Dirk Wiesenthal 2020-01-15 13:09:19 CET

Automatic test did not pass. Seems we overlooked something? At least the test needs to be fixed, but it may be that there is something else wrong.

Comment 8 Dirk Wiesenthal 2020-01-29 10:06:45 CET

Fixed in univention-management-console-web-server
  univention-management-console 11.0.4-52A~4.4.0.202001290956

At some point in UMC, the "Processor" dies, and with it the username/password information for new UMC modules. When a new UMC module is to be started, a new Processor is added and new credentials are requested by the client.

The client is UMC-Webserver in this case. And it used to provide the SAML session again. Even if it was upgraded before.

We fixed the behaviour and added a test:
  82_saml/32_umc_upgrade_session

It tests with the SAML test lib. For reasons yet unknown, a second, Selenium based test did not give proper results.

Comment 9 Felix Botner 2020-02-06 18:00:22 CET

Now i get 

 Your session has expired, please login again.
 The current session timed out. Please login again.

 => redirect to the umc login page

after nearly every app installation. 


This happened before too, but not as regular as with this change.

Comment 10 Jürn Brodersen 2020-02-07 17:03:45 CET

(In reply to Felix Botner from comment #9)
> Now i get 
> 
>  Your session has expired, please login again.
>  The current session timed out. Please login again.
> 
>  => redirect to the umc login page
> 
> after nearly every app installation. 
> 
> 
> This happened before too, but not as regular as with this change.

You ran into bug 50804. Basically installing an app on a dc master causes all saml sessions to be invalidated.

Comment 11 Felix Botner 2020-02-10 11:12:38 CET

as disscused, resolved

Comment 12 Felix Botner 2020-02-10 11:19:14 CET

OK - no extra password dialog after umc restart
OK - yaml

Comment 13 Erik Damrose 2020-02-12 15:40:36 CET

<http://errata.software-univention.de/ucs/4.4/442.html>