Re: [ballrace-developer] superuser-action

[Matthias S. <mat...@gs...>]

okee...h=F6rt sich ja ganz funktionierend an!
Dass man die Reseller-Session evtl. nicht aufrechthalten kann finde ich n=
icht schlimm. Ich gehe
von pers=F6nlichen Erfahrungen aus wenn ich sage, dass ich so gut wie nie=
, nachdem ich etwas als Kunde
konfiguriert habe, mich nochmal als Reseller einloggen m=FCsste.
Meist verwende ich "Confixx" nur entweder als Reseller oder als Customer,=
 selten als beides, und
wenn, dann nur in der Reihenfolge Reseller - Customer.....nie umgekehrt u=
nd der Fall, dass ich
zur=FCck m=F6chte (zu Reseller) kommt auch nie vor!

Selbstverst=E4ndlich w=E4re es aber ein nettes Feature wenn man wieder zu=
r=FCck kommen k=F6nnte (zur
Reseller-Session) ...

Matthias

___________________________________________

GS-fabline  GbR
Martin Grotzke, Matthias Schmidt GbR
   Wilhelmstr. 11   D-78120 Furtwangen
   tel  +49 (0) 7723.929901
   fax  +49 (0) 7723.929905

Matthias Schmidt
   mailto   mat...@gs...
   mobil    +49 (0) 170.2822201
___________________________________________



Saturday, December 6, 2003, 10:44:31 AM, you wrote:

mg> hello,

mg> wegen der frage ob es moeglich ist eine "superuser"-action fuer
mg> reseller zu bauen damit die sich als customer einloggen koennen
mg> hier mal ein unproofed concept:

mg> 1  reseller klickt bei einem seiner kunden "su", der request geht auf
mg>    eine "SuperUserAction" welche versch. informationen zu reseller un=
d
mg>    kunde speichert und weiterleitet auf eine ressource die explizit n=
ur
mg>    fuer customer zugaenglich ist.
mg> 2  tomcat leitet weiter an login-"page" (/login.do) und speichert sic=
h
mg>    den pfad der urspruenglich gewuenschten ressource.
mg> 3  in der login.do-action wissen wir dass gerade ein reseller eine
mg>    superuser-action ausfuehren will, bauen einen wrapper fuer
mg>    den HttpServletRequest (implementiert auch HttpServletRequest und
mg>    bekommt im konstruktor den HttpServletRequest von tomcat, an den e=
r
mg>    die "standard"-operationen delegiert). der wrapper bekommt dann vo=
n
mg>    uns die authentifizierungsinformationen fuer den customer (was son=
st
mg>    im formular eingegeben werden wuerde), dann wird nach
mg>    /j_security_check weitergeleitet (ist die url auf der tomcat die
mg>    authentication durchfuehrt)
mg> 4  tomcat fragt auf /j_security_check benutzername und passwort ab
mg>    (j_username, j_password), das nimmt er aus dem HttpServletRequest
mg>    den er bekommt, was hier dann unser wrapper ist, der ihm also
mg>    die richtigen auth-infos geben kann.
mg> 5  auth erfolgreich -> tomcat leitet weiter zu der urspruenglich
mg>    gewuenschten ressource (die er sich gespeichert hatte), das waere
mg>    dann die homepage vom customer-interface.

mg> offen noch:
mg> - evtl ist es nicht moeglich beide sessions (reseller + customer)
mg>   parallel laufen zu lassen, also auch explizit eine neue session
mg>   zu erzeugen ohne die "alte" zu zerstoeren, dann muesste man sich
mg>   einen workaround bauen der wenigstens dann sowas wie "exit to
mg>   reseller" in der su-umgebung zur verfuegung stellt

mg> soweit die ueberlegung, man muesste das mal implementieren zur
mg> ueberpruefung, da kommen bestimmt noch ein, zwei sachen die nicht
mg> bedacht sind.

mg> cheers,
mg> martin



mg> -------------------------------------------------------
mg> This SF.net email is sponsored by: SF.net Giveback Program.
mg> Does SourceForge.net help you be more productive?  Does it
mg> help you create better code?  SHARE THE LOVE, and help us help
mg> YOU!  Click Here: http://sourceforge.net/donate/
mg> _______________________________________________
mg> ballrace-developer mailing list
mg> bal...@li...
mg> https://lists.sourceforge.net/lists/listinfo/ballrace-developer