Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung | |||
de:shibslohttpd:functioning [2015/12/09 11:17] – [Sonderzustände] Schreiterer, Frank | de:shibslohttpd:functioning [2015/12/09 11:17] (aktuell) – [Sonderzustände] Schreiterer, Frank | ||
---|---|---|---|
Zeile 27: | Zeile 27: | ||
- Im Context „lazy“ gibt es beim ersten Aufruf einen Zustand, bei dem weder die Shib-Session-ID noch die Anwendungs-Session-ID vorhanden sind, was eine gültige Anfrage sein muss. Hier wird als Rückgabeparameter „doLogin“ geliefert. Es liegt bei der Administration, | - Im Context „lazy“ gibt es beim ersten Aufruf einen Zustand, bei dem weder die Shib-Session-ID noch die Anwendungs-Session-ID vorhanden sind, was eine gültige Anfrage sein muss. Hier wird als Rückgabeparameter „doLogin“ geliefert. Es liegt bei der Administration, | ||
- Im Moment der durchgeführten Authentifizierung mit Shibboleth darf noch keine Anwendungs-Session vorhanden sein, aber es muss eine Shib-Session-ID existieren. Dieser Zustand muss als gültige Anfrage erklärt werden, aber es muss noch sicher gestellt werden, dass zur Shib-Session-ID die korrekte Anwendungs-Session zugeordnet wird. Hier wird als Rückgabeparameter „doAppSession“ geliefert. \\ Auf diesen Zustand muss die Administration reagieren, sonst besteht die Gefahr, dass ein Cookie einer vorherigen Session der Anwendung eingeschleust wird! Es muss ein zusätzlicher Request erfolgen, in dem die Anwendungs-Session in den Variablen für das Prüfskript zur Verfügung gestellt werden. Hierzu bestehen zwei Möglichkeiten: | - Im Moment der durchgeführten Authentifizierung mit Shibboleth darf noch keine Anwendungs-Session vorhanden sein, aber es muss eine Shib-Session-ID existieren. Dieser Zustand muss als gültige Anfrage erklärt werden, aber es muss noch sicher gestellt werden, dass zur Shib-Session-ID die korrekte Anwendungs-Session zugeordnet wird. Hier wird als Rückgabeparameter „doAppSession“ geliefert. \\ Auf diesen Zustand muss die Administration reagieren, sonst besteht die Gefahr, dass ein Cookie einer vorherigen Session der Anwendung eingeschleust wird! Es muss ein zusätzlicher Request erfolgen, in dem die Anwendungs-Session in den Variablen für das Prüfskript zur Verfügung gestellt werden. Hierzu bestehen zwei Möglichkeiten: | ||
- | | + | |
- | - am Apache-Webserver einen Refresh-Header dem Request hinzuzufügen, | + | - am Apache-Webserver einen Refresh-Header dem Request hinzuzufügen, |
Siehe auch: [[de: | Siehe auch: [[de: |