Apache & CGI / Userprofile

[S.Neinawaie]

Hallo

Ich möchte in Zukunft via Apache, RPG & CGI Inhalte im Web ausgeben. Allerdings bin ich mir nicht sicher wie ich auf Objektberechtigungen Rücksicht zu nehmen habe.

Standardmäßig laufen die Apache & CGI Jobs als QTMHHTTP & QTMHHTP1.
Allerdings fehlt diesen Usern natürlich die Berechtigung auf die Datenbibliothek, daher bekomme ich bei jedem Request einen Fehler (Versuch die LIBL zu setzen scheitert).

Wie handhabt Ihr so etwas?
Verwendet Ihr die APIs QSYGETPH & QWTSETP um mitten im Programm den Benutzer zu wechseln? Falls ja -> Es ist lt. Doku notwendig *USE (oder sogar *ALLOBJ/*SECADM) Rechte auf das *USRPRF unter dem gearbeitet werden soll zu vergeben -> Gibt es nicht eine bessere Lösung?


Herzlichen Dank im Voraus,
Sam

[mk]

Hi,

die QTMHH-- Benutzerprofile müssen natürlich Rechte für die LIBs etc. bekommen damit die
Requests auch verarbeitet werden können.

Nachdem Du dich durch das CGI gequält hast solltest Du mal den ZendServer ausprobieren.
In Verbindung mit PHP ist zwar vieles anders, aber auch vieles einfacher.
Viele Erfolg
Michael

[BenderD]

... die QTMHH++ Benutzer dürfen natürlich keinesfalls Berechtigung für die Libs bekommen, sie dürfen allenfalls Berechtigung für CGI Programme haben und da eigentlich auch nur für die Controllerschicht. Alles andere wird von dort aus aufgerufen und bringt genau die Rechte mit, die es braucht. Profile switch würde ich auch vermeiden wollen, adopted Authority müsste da reichen.

D*B
, der sich spaßigere Dinge vorstellen kann als CGI.

[Pikachu]

Wie wär's mit der ServerUserID-Direktive?

ServerUserID BENUTZERNAME

[S.Neinawaie]

Herzlichen Dank für eure Antworten - würde mich natürlich über weitere Erfahrungsberichte freuen.

Danke,
Sam

[Fuerchau]

Bei Standardberechtigungen steht ja eigentlich alles auf *PUBLIC *USE. Somit kommen auch die QTM-Profile an alle Anwendungsdaten.
Mit dem "App"-User und Ausführung *OWNER gibt es keinesfalls Probleme.
Man sollte jedoch nicht auf die Idee verfallen, allen "externen" Usern der Web-Anwendung AS/400-Profile zuzuweisen. Das kann schnell in die Millionen gehen und sprengt de Rahmen.
Hier ist eine eigene User/Kennwort-Verwaltung erforderlich.

[AG1965_2]

Erspar' Dir den RPG-CGI-Ausflug, den nahezu jeder anfangs unternimmt - php ist viel praktischer. Und von dort aus kannst du noch immer Deine RPG-Programme aufrufen.
LG Toni

[BenderD]

Bei Standardberechtigungen steht ja eigentlich alles auf *PUBLIC *USE.

... was einen groben Schnitzer darstellt. BTW: Standard für Daten ist SQL und da steht alles auf *PUBLIC *EXCLUDE und das ist auch gut so!!!

D*B

[Fuerchau]

Aber nur, wenn ich auch die "Collection", also Lib per CREATE SCHEMA erstellt habe.
Ansonsten zieht auch bei SQL die CRTAUT, die beim CRTLIB auf *SYSVAL und somit auf QCRTAUT und da sogar auf *CHANGE steht.
Gefährlich wird es dann, wenn man nun den Systemwert einfach auf *EXCLUDE setzt da dies sofort auf alle Libs mit *SYSVAL wirkt.
Auch wenn viele mit SQL arbeiten, wird meist mit CRTLIB erstellt.

[BenderD]

Aber nur, wenn ich auch die "Collection", also Lib per CREATE SCHEMA erstellt habe.
Ansonsten zieht auch bei SQL die CRTAUT, die beim CRTLIB auf *SYSVAL und somit auf QCRTAUT und da sogar auf *CHANGE steht.
Gefährlich wird es dann, wenn man nun den Systemwert einfach auf *EXCLUDE setzt da dies sofort auf alle Libs mit *SYSVAL wirkt.
Auch wenn viele mit SQL arbeiten, wird meist mit CRTLIB erstellt.

... Bibliotheken mit Produktionsdaten müssen immer public exclude sein, berechtigen kann man die dann immer noch, am einfachsten über eine AUTL, die man auch noch beim CRTAUT der Lib eintragen kann.

D*B

[AG1965_2]

Wenn Du die Hardcore-Antwort möchtest, wenn der Apache nur File-Server spielt:
Du kannst z.B. bei Basic Authentication mit der Benutzer-Id, die der Client angibt, arbeiten.
Nur macht das - schon allein aus optischen Gründen und Goodies wie Password-Rücksetz-Mails - heutzutage eigentlich niemand mehr.

Berechtigungen werden in der Applikation abgefackelt, die Applikation hat das Recht, auf die Daten zuzugreifen, ein Benutzer nicht (unbedingt) und ein Web-Benutzer schon gar nicht. Den gibt es dann nämlich gar nicht als echten IBM i - User.

Aber wenn Du noch immer sehen willst, wie das geht, Shlomo Vanunu hat das beschrieben:
https://support.zend.com/hc/en-us/ar...-user-profiles
(Es handelt sich in jedem Fall um einen Dialog Client <--> Server in HTTP. Das kannst Du auch per CGI oder php produzieren. In dem Fall führen wirklich sehr, sehr viele Wege ans Ziel.)