Re: RE : RE : [sdx-developers] Interface d'administration

[Pierrick Brihaye]

Martin Sevigny a écrit:

> Peut-être, mais on avait pensé que le SU pourrait gérer toutes les
> applications également... 

C'est comme ça que je voyais les choses... avant :-) Maintenant que j'ai 
un peu plus de recul (notamment grâce à ton très pertinent rappel sur 
l'utilisateur root d'Unix), je verrais bien dans le volet SU :

- déconnection (avec retour à un volet "standard")
- modification du SU
- reconfiguration / ajout / fermeture / (ré)ouverture / destruction(?) 
d'applications.

> Donc c'est plus facile de les regrouper
> (techniquement et cognitivement pour le SU)...

Si ce parti est conservé, je persiste donc dans ma suggestion selon 
laquelle il faut envisager une approche *très* cognitive :-)

> Comment définis-tu "sortir" dans une application Web? S'il va sur
> Google, on fait une entente avec Google pour intercepter cet événement ?
> ;-)

Tant qu'on reste dans SDX, on peut contrôler la navigation. Dans un 
volet SU, il suffirait de virer les liens vers les applis (ou alors de 
spécifier que la traversée des dits liens fait perdre le privilège SU).

Pour le gars qui va faire un tour sur Google entre temps (c'est pas bien 
: quand on fait de la gestion de serveur, on doit s'investir à fond), 
c'est effectivement plus compliqué (ça concerne la durée de vie des 
cookies). Le truc serait de faire :

1) on a un cookie qui dit que c'est un SU :
a) accès au contexte SU : OK
b) accès à un contexte non SU : tout est concevable, depuis une 
redirection d'office au contexte SU jusqu'à une erreur "permission denied".
2) on n'a pas de cookie qui dit que c'est un SU :
l'inverse des cas précédents.

Mais bon, il est vrai qu'il est difficile de trancher avec le peu de 
feedback qu'on a jusqu'à maintenant.

A+


--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden