JBoss6 Remoting

[Gast2]

Gleiches Problem wo hast du die config datei hingetan?

 

[TheDarkRose]

Die kannst du hintun wo du willst, muss diese aber über das Property java.security.auth.login.config angeben.
JAAS Login Configuration File

 

[Gast2]

Die kannst du hintun wo du willst, muss diese aber über das Property java.security.auth.login.config angeben.
JAAS Login Configuration File

Argh stimmt hab ich eigentlich gelesen...

In dem EJB Project ist ja eine ejb-jar.xml vorhanden. Zusätzlich muss noch eine jboss.xml erstellt werden. Dort sind dann deine EJB's und Methoden abzusichern. Chapter*1.*J2EE Declarative Security Overview

Ich hab keine ejb-jar.xml ich verwende ejb3.1, da benötige ich keine mehr.

Das mit der JBoss.xml habe ich nur nicht richtig durchschaut. Brauch ich eine jboss.xml oder reicht das web.xml aus?

Hab leider auch noch nicht rausgefunden wie man JBossSX transparent in einen Application Client einbindet.

Ja ich hab jetzt nur mal den LoginContext aufgerufen.

 

[TheDarkRose]

Ich hab keine ejb-jar.xml ich verwende ejb3.1, da benötige ich keine mehr.

Stimmt, da geht das ja mit Annotations.

Das mit der JBoss.xml habe ich nur nicht richtig durchschaut. Brauch ich eine jboss.xml oder reicht das web.xml aus?

Diese muss in dem EJB Project liegen, wo du mindestens die Security Domain angibst die verwendet wird. Brauchst du auf jeden Fall wenn man es direkt per JAAS mit ClientLoginModule im AppClient versucht. Ich glaub bei der LoginInitialContextFactory (wie oben beschrieben) is das nicht mehr nötig, kann aber nicht schaden.
Chapter*3.*JBoss Security Model
[XML]<jboss>
<security-domain>my-sec-dom</security-domain>
</jboss>[/XML]

eine web.xml brauchst du gar nicht, da hier ja keine WebApplication am Werk ist.

Ja ich hab jetzt nur mal den LoginContext aufgerufen.

Ja, aber mit ClientLoginModule werden nur die Principals in ein Subject kopiert. Mehr macht das ja nicht. Die Serverseitige Authentifizierung findet ja erst beim ersten JNDI Lookup statt.

 

[Gast2]

Hab dein Edit gar nicht gesehen hast du die Klasse schon gefunden in welchem jar die liegt bei ist sie in jbosssx-client.jar nicht enthalten.

Ok in der jbosssx-as-client.jar ist sie drin.

 

[Gast2]

EDIT: Für remote client JndiLoginInitialContextFactory benutzen

Aber klappt auch nicht beim Context holen:
Erst wenn ich auf das Bean zugreife bekomme ich eine expection

Exception in thread "AWT-EventQueue-0" javax.ejb.EJBAccessException: Invalid User
	at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:161)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)

 

[TheDarkRose]

Warum die JndiLoginInitialContextFactory?

 

[Gast2]

Warum die JndiLoginInitialContextFactory?

Weil er sonst mein Protokoll nicht findet... Steht ja unten extra für remote clients. Oder der Context.SECURITY_PROTOCOL gibt den domain auf dem Server an?


Bei LoginInitialContextFactory,bekomm ich auf den Client die Fehlermeldung

Caused by: javax.security.auth.login.LoginException: Für prototyp sind keine Anmeldemodule konfiguriert.
	at javax.security.auth.login.LoginContext.init(LoginContext.java:256)
	at javax.security.auth.login.LoginContext.<init>(LoginContext.java:403)
	at org.jboss.security.jndi.LoginInitialContextFactory.getInitialContext(LoginInitialContextFactory.java:84)
	... 50 more

login.config.xml
[XML]
<application-policy name="prototyp">
<authentication>
<login-module
code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option
name="usersProperties">
props/prototyp-users.properties
</module-option>
<module-option
name="rolesProperties">
props/prototyp-roles.properties
</module-option>
</login-module>
</authentication>
</application-policy>
[/XML]

Wie hast du es gemacht?

 

[TheDarkRose]

argh, der InitialContext wird ja auf dem Client ausgeführt. Also wird wieder ein JAAS Aufruf am Client hervorgerufen. Genau das was mir nicht brauchen. Denn JAAS auf clientseite ist unsicher durch die Konfigurierbarkeit, da jemand z.b. eine LdapExtLoginModule durch etwas anderes ersetzen könnte. Gut, da ja JAAS dann die Principals an den Server sendet, macht dieser ja auch noch seine Auth und die gefälschten Daten würden dann natürlich abgelehnt werden. Trotzdem nicht schön, wenn sich dem Hacker die Oberfläche so weit offenbart bis zum ersten EJB Inject. So mal ein bisschen Theorie nebenbei.

JndiLoginInitialContextFactory wär dann eh das richtige. Diese verknüpft die Principals mit der SecurityAssocation, welche dann bei jeden JNDI Lookup zu einen EJB mitgesendet werden sollte. Dann authentifiziert dich der Server jedes Mal.
Also sollte man direkt nach den erzeugen des InitialContext einen Lookup machen, und sei es nur auf eine Dummy EJB, um zu testen ob die Logindaten stimmen. Oder z.B. eine EJB die einem die Rollen zurückliefert, nach der man die Oberfläche aufbauen kann.

Edit: ich hab leider noch nichts von heute gemacht, da ich noch immer in der Arbeit sitze :noe:

 

[Gast2]

Also vielleicht nochmal deutlicher:

Auf dem Server im login-config.xml habe ich den eintrag:
[XML]
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag="required"/>
</authentication>
</application-policy>

<application-policy name="prototyp">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name="usersProperties">props/prototyp-users.properties</module-option>
<module-option name="rolesProperties">props/prototyp-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>
[/XML]

dann die beiden properties files prototyp-users.properties:

admin=admin

props/prototyp-roles.properties

admin=Admin

Auf dem Client:

		prop.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.security.jndi.LoginInitialContextFactory");
		prop.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
		prop.put(Context.PROVIDER_URL, "jnp://localhost:1099/");
		prop.put(Context.SECURITY_PROTOCOL, "prototyp");
		prop.put(Context.SECURITY_CREDENTIALS, "admin");
		prop.put(Context.SECURITY_PRINCIPAL, "admin");
		
//        InitialContext ctx = new InitialContext(prop);
//		JndiLoginInitialContextFactory initialContextFactory = new JndiLoginInitialContextFactory();
		LoginInitialContextFactory initialContextFactory = new LoginInitialContextFactory();
        // lookup the account manager bean
        Context context = initialContextFactory.getInitialContext(prop);

und das auth.config file, das soll ich nur die Authenfizierung an den Server weiter geben ?

prototyp {
   // jBoss LoginModule
   org.jboss.security.ClientLoginModule  required
   ;
};

So anmelden klappt greif ich auf das bean zu:
Bekomm ich ein invalid user
1. Frage warum ???:L
2. wenn ich einen falschen Benutzer mitgebe klappt die Anmeldung trotzdem dachte dann ist der context null :bahnhof:...

mhm

 

[TheDarkRose]

Eigentlich müsstest du eine AuthenticationException bekommen.

Quelltexte:
org.jboss.security.jndi.LoginInitialContextFactory (Java2HTML)
org.jboss.security.jndi.JndiLoginInitialContextFactory (Java2HTML)


Edit: ein LoginContext.login() klappt beim ClientLoginModule immer, da dieser nur die Principals in das Subject schreibt ohne Authentifizierung. Diese sollte dann am Server geschehen.

 

[Gast2]

argh, der InitialContext wird ja auf dem Client ausgeführt. Also wird wieder ein JAAS Aufruf am Client hervorgerufen. Genau das was mir nicht brauchen. Denn JAAS auf clientseite ist unsicher durch die Konfigurierbarkeit, da jemand z.b. eine LdapExtLoginModule durch etwas anderes ersetzen könnte. Gut, da ja JAAS dann die Principals an den Server sendet, macht dieser ja auch noch seine Auth und die gefälschten Daten würden dann natürlich abgelehnt werden. Trotzdem nicht schön, wenn sich dem Hacker die Oberfläche so weit offenbart bis zum ersten EJB Inject. So mal ein bisschen Theorie nebenbei.

Ja das habe ich ja im obigen Post mal versucht würde ich nicht so schlimm finden.

JndiLoginInitialContextFactory wär dann eh das richtige. Diese verknüpft die Principals mit der SecurityAssocation, welche dann bei jeden JNDI Lookup zu einen EJB mitgesendet werden sollte. Dann authentifiziert dich der Server jedes Mal.
Also sollte man direkt nach den erzeugen des InitialContext einen Lookup machen, und sei es nur auf eine Dummy EJB, um zu testen ob die Logindaten stimmen. Oder z.B. eine EJB die einem die Rollen zurückliefert, nach der man die Oberfläche aufbauen kann.

So dass habe ich auch mal versucht. Geleiche xml von oben auf dem Server

Client

		prop.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.security.jndi.JndiLoginInitialContextFactory");
		prop.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
		prop.put(Context.PROVIDER_URL, "jnp://localhost:1099/");
		prop.put(Context.SECURITY_PROTOCOL, "prototyp");
		prop.put(Context.SECURITY_CREDENTIALS, "admin");
		prop.put(Context.SECURITY_PRINCIPAL, "admin");
		
		JndiLoginInitialContextFactory initialContextFactory = new JndiLoginInitialContextFactory();
        Context context = initialContextFactory.getInitialContext(prop);

Hat funktioniert. Wenn ich einen falschen User mitgebe beim ersten lookup

Exception in thread "AWT-EventQueue-0" javax.ejb.EJBAccessException: Invalid User

:toll::toll:

So und nun nach langer Geburt , wie bekomme ich ein Bean mit den Session Infos in EJBContext

EDIT: Die jboss.xml braucht man auf jeden fall sonst werden die falschen user nicht erkannt!

 

[TheDarkRose]

Warum hast du da zusätzlich ein [c]new JndiLoginInitialContextFactory();[/c]. Eigentlich sollte [c]Context = new InitialContext(env);[/c] doch reichen? Denn der Konstruktor von InitialContext sollte zur Laufzeit die ContextFactory anhand der env Properties bestimmen und diese Factory aufrufen.

Edit: mhm, denn die jboss.xml bestimmt ja welche Security Domain nun verwendet wird.

 

[Gast2]

Warum hast du da zusätzlich ein [c]new JndiLoginInitialContextFactory();[/c]. Eigentlich sollte [c]Context = new InitialContext(env);[/c] doch reichen? Denn der Konstruktor von InitialContext sollte zur Laufzeit die ContextFactory anhand der env Properties bestimmen und diese Factory aufrufen.

Ja hast recht ist jetzt doppelt drin. naja irgenwie doof, dass man nicht beim login gleich eine exception bekommen kann, sondern erst beim 1. EJB aufruf.

aber meine @RolesAllowed("admin") klappt noch nicht damit sperr ich alles , mal schauen was da schief läuft.

Nun ja aber das ist mir nicht so wichtig, eher wie ich jetzt die Session infos in den EJBContext bekomme

 

[TheDarkRose]

Hmm, vl Case Sensitive?

wegen dem Context, füge mal folgendes Feld in deine EJB und versuch dann in einer Methode aufzrufen

@Resource SessionContext ctx;

 

[Gast2]

Hmm, vl Case Sensitive?

Nee schon probiert.

wegen dem Context, füge mal folgendes Feld in deine EJB und versuch dann in einer Methode aufzrufen

@Resource SessionContext ctx;

Ja das hab ich gelesen...
Aber jetzt muss ich ein Singelton machen mit einer Map<Id?,MeinBean> mhm? Ich muss mal drüber schlafen

 

[TheDarkRose]

Nee schon probiert.

Füge noch bei der class Definition ein [c]@DeclareRoles("Admin")[/c] hinzu.

Aber jetzt muss ich ein Singelton machen mit einer Map<Id?,MeinBean> mhm? Ich muss mal drüber schlafen

Anderes unabhängiges Problem?

 

[Gast2]

Anderes unabhängiges Problem?

Nein das Ausgangsproblem, ich brauche eine Bean, die einige Informationen beinhaltet für jede Session

 

[Gast2]

Benutze einen Service oder oder Singleton Bean. Dort wird zu jedem User der Kontext gehalten. Bei der Erstellung einer Session (ein SFSB) wird der Kontext angelegt, beim Löschen der Session wird der Kontext gelöscht, d.h. die Sessionbean regelt auch den Lebenszyklus des Kontext. Der User authentifiziert sich mit JAAS und über EJBContext (Java EE 6 ) bekommst du immer den aktuellen User in einem Bean.

Könntest mit die Idee nochmal bischen genauer erklären?

Ich habe eine Singelton Bean z.B. SessionContainer mit einer Map<Id oder Oder,Kontext>.
Was genau ist Kontext meine eigene Bean mit meinen Infos oder der EJBContext bzw. SessionKontext?
Ist die Session Bean meine eigene Bean?

Der User authentifiziert sich mit JAAS und über EJBContext (Java EE 6 ) bekommst du immer den aktuellen User in einem Bean.

ok mit

@Resource private EJBContext context

hole ich mit den Context und über

context.getCallerPrincipal()

hole ich mir den User und darüber über mein Singelton die Session Infos?

Kommt das so ungefähr hin?

Die Idee das ein User mehrer Session haben kann, war mir auch noch nicht so klar, aber erst mal klein anfangen , oder hast du meine dass ich mir selber eine eindeutige Session ID generieren lassen soll mit org.jboss.util.id.GUID?

 

[FArt]

Ja, so könnte ich mir das vorstellen.

Der Client erstellt eine Session (SFSB), authentifiziert sich gegenüber dem Server. Das SFSB kann das Singleton Bean injiziert bekommen. Dieses Bean hält die kontextabhängigen Daten, Schlüssel sind die Prinzipalinformationen (also der User). Das SFSB sollte über create und destroy die Lebensdauer des Kontextes steuern.
Wenn jetzt ein User mehrere Sessions gleichzeitig haben soll (mit unterschiedlichen Kontexten), könnte man die Prinzipalinformationen um eine auf Clientseite generierte ID erweitern, die dazu dient die Session zu identifizieren. Diese ID kann dann als Schlüssel verwendet werden.

 

[Gast2]

Der Client erstellt eine Session (SFSB), authentifiziert sich gegenüber dem Server.

Damit habe ich noch Probleme und woher ich jetzt die User Info genau bekomme.

Also mal was ich auf dem Server habe:

@Stateful
public class PricePilotSession {

	private Object uuid;
	@EJB
	private ContextContainer container;
	@Resource(mappedName="UUIDKeyGeneratorFactory")
	private KeyGeneratorFactory generatorFactory;	

	@PostConstruct
	public void create(){
		   KeyGenerator kg;
		try {
			kg = generatorFactory.getKeyGenerator();
			 uuid = kg.generateKey();
		} catch (Exception e) {
			e.printStackTrace();
		}
		container.addContext(uuid, new Context());
	}
	
	@PreDestroy
	public void destroy(){
		container.removeContext(uuid);
	}
}

public class Context {

	public String info;
	public String username;
//usw.
}

@Singleton
@Startup
public class ContextContainer {

	Map<Integer,Context> map = new HashMap<Integer, Context>();
	
}

@Stateful
public class AngebotRemoteServiceImpl implements AngebotRemoteService{

	@Override
	public Set<Angebot> getAngebote() {

                          // wie bekomme ich jetzt hier die Infos rein???
		return angebote;
	}
}

Client:

	public void login(String name, char[] pwd) throws LoginException, NamingException  {
		prop.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.security.jndi.JndiLoginInitialContextFactory");
		prop.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
		prop.put(Context.PROVIDER_URL, "jnp://localhost:1099/");
		prop.put(Context.SECURITY_PROTOCOL, "prototyp");
		prop.put(Context.SECURITY_CREDENTIALS, pwd);
		prop.put(Context.SECURITY_PRINCIPAL, name);

                         Context context = new InitialContext(prop);

Mir fehlt jetzt die Sache wie ich die Infos in einen Service bekomme und woher ich jetzt die UserDaten nehme?
Und wenn ich auf Ressource zugreife bekomme ich auch noch ein lookup Errors =(.

Caused by: java.lang.NoSuchMethodError: javax.annotation.Resource.lookup()Ljava/lang/String;

 

[FArt]

Die Information bekommst du aus dem Principal. Natürlich brauchst du u.U. eine eigene Implementierung.

Ich habe mich mal etwas intensiver mit der JSR-299 beschäftigt und bin zu dem Schluss gekommen, dass es mittleweile wohl eine bessere Lösung gibt. Im Kapitel 6 (Scopes and Contexts) geht es auch um Kontexte, die so funktionieren wie hier gefordert. Im Prinzip gibt es schon eine fertige Implementierung für Webapplikationen. Man muss wohl aber (wenn ich das auf den ersten Blick recht verstanden habe) einen eigenen Context verwenden bzw. dem Bean injecten, der von der Applikation gesteuert wird (im Falle der Webanwendung macht das das Servlet über seinen Session-Lifecycle).

JBoss 6 kommt mit Weld daher, der Referenzimplementierung. Wenn ich Zeit habe, werde ich mal einen PoC klöppeln (kann man immer mal brauchen).
Ich würde also empfehlen u.U. in diese Richtung weiter zu forschen. Mein "Ansatz" ist wohl altbacken, würde aber funktionieren. Der JSR-299 Context macht wohl auch nichts anderes, ist nur wesentlich angenehmer in der Verwendung.

 

[TheDarkRose]

@SirWayne
Kannst du mir mal deine EAR schicken, irgendwie hab ich Probleme das umzusetzen was wir hier diskutiert haben :bahnhof:

 

[Gast2]

@SirWayne
Kannst du mir mal deine EAR schicken, irgendwie hab ich Probleme das umzusetzen was wir hier diskutiert haben :bahnhof:

Hier sind mal beide Projekte

 

[Gast2]

Die Information bekommst du aus dem Principal. Natürlich brauchst du u.U. eine eigene Implementierung.

Ja daran scheitert es gerade, ich weiß nich wo ich ansetzen muss. Mir fehlt der Startpunkt.

Ich habe mich mal etwas intensiver mit der JSR-299 beschäftigt und bin zu dem Schluss gekommen, dass es mittleweile wohl eine bessere Lösung gibt. Im Kapitel 6 (Scopes and Contexts) geht es auch um Kontexte, die so funktionieren wie hier gefordert. Im Prinzip gibt es schon eine fertige Implementierung für Webapplikationen. Man muss wohl aber (wenn ich das auf den ersten Blick recht verstanden habe) einen eigenen Context verwenden bzw. dem Bean injecten, der von der Applikation gesteuert wird (im Falle der Webanwendung macht das das Servlet über seinen Session-Lifecycle).

Okay schau ich da nochmal. Ja die fertige Implmentierung ist ja der SessionScope für Weapps, oder was meinst du?
Was meinst du mit Context eine EJBContext? Werd mir das Kapitel nochmal anschauen.

EDIT:
Meinst du Kapitel 5?
Chapter*5.*Scopes and contexts

For example, if we have a session-scoped bean, CurrentUser, all beans that are called in the context of the same HttpSession will see the same instance of CurrentUser. This instance will be automatically created the first time a CurrentUser is needed in that session, and automatically destroyed when the session ends.

Genau so ein Verhalten will ich =), nur halt mit RMI

Meinst du ich muss einen eigene Scope Annotation machen und dazu einen eigenen Context siehe 5.1?

 

[FArt]

Genau so ein Verhalten will ich =), nur halt mit RMI

Nicht für RMI. Für Beancalls, egal mit welchem Protokoll.

Meinst du ich muss einen eigene Scope Annotation machen und dazu einen eigenen Context siehe 5.1?

So habe ich das verstanden. Dürfte nicht allzu schwer sein, denn so einen ähnlichen Context gibt es ja schon. Lediglich die Steuerung des Lebenszyklus müsste noch übernomen werden, denke ich.

 

[Gast2]

So habe ich das verstanden. Dürfte nicht allzu schwer sein, denn so einen ähnlichen Context gibt es ja schon. Lediglich die Steuerung des Lebenszyklus müsste noch übernomen werden, denke ich.

Hier habe ich nur etwas ausführlicheres gefunden Kapitel 6.
http://relation.to/service/File/12829
Werd ich mir mal anschauen, ob ich was finde.
Bis jetzt fehlt mir noch das Verständniss wo ich mich einklinken kann und selber etwas Steuern kann. Welchen Context meinst du der ähnlich ist hab grad mal die Hierarchie von spi.Context angeschaut gibt ja einige. Such grad die sourcen mal dazu

EDIT: Sieht ganz interessant aus

/**
 * Abstract base class for representing contexts with thread local bean storage
 * 
 * @author Pete Muir
 */
public abstract class AbstractThreadLocalMapContext extends AbstractMapContext

 

[Gast2]

Also ich versuche grad sowas hier:

import static java.lang.annotation.ElementType.FIELD;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.TYPE;

import java.lang.annotation.Inherited;
import java.lang.annotation.Target;

import javax.enterprise.context.NormalScope;

@Target(value = {TYPE, METHOD, FIELD })
@NormalScope
@Inherited
public @interface MyScope
{
}

import java.lang.annotation.Annotation;

import javax.enterprise.context.spi.Context;
import javax.enterprise.context.spi.Contextual;
import javax.enterprise.context.spi.CreationalContext;

public class MyContext extends AbstractThreadLocalMapContext-->Klasse gibts leider{

	/**
	 * Constructor
	 */
	public MyContext() {
		super(MyScope.class);
	}

	@Override
	public String toString() {
		String active = isActive() ? "Active " : "Inactive ";
		String beanStoreInfo = getBeanStore() == null ? "" : getBeanStore()
				.toString();
		return active + "session context " + beanStoreInfo;
	}

	@Override
	public void setActive(boolean active) {
		super.setActive(active);
	}

	@Override
	public void setBeanStore(BeanStore beanStore) {
		super.setBeanStore(beanStore);
	}

}

import javax.enterprise.inject.spi.Extension;

public class MyExtension implements Extension{

}

Ist das der richtige Weg? Warum habe ivh die ganzen org.jboss.weld.context Klasse nicht?
Was kommt den jetzt genau in die Extension rein?

 

[Gast2]

Also ich hab jetzt zwar was selber gebasteltetes hinbekommen mit einem Interceptor, aber ich finds ehrlich gesagt nicht sehr toll...
Außerdem muss ich bei jedem Call die SessionID als Parameter mitgeben, um das Mapping hinzubekommen auch häßlich.

Jemand noch eine bessere Idee?

 

[FArt]

Also ich hab jetzt zwar was selber gebasteltetes hinbekommen mit einem Interceptor, aber ich finds ehrlich gesagt nicht sehr toll...
Außerdem muss ich bei jedem Call die SessionID als Parameter mitgeben, um das Mapping hinzubekommen auch häßlich.

Jemand noch eine bessere Idee?

Das Prinzip ist genau so richtig ok. Woher soll der Server denn sonst den Zusammenhang zur Session, die ja vom Client gepflegt wird, kennen und mit dem Call in Verbindung bringen. Läuft doch in HTTP auch so, nur dass du es nicht mitbekommst (url rewriting oder cookies).
Du kannst aber die Schnittstelle von diesen Metainformationen frei halten, wie es z.B. auch JAAS macht:
Der Client pflegt die ID und deren Lifycycle. Bei jedem Call wird die ID über eine clientseitigen Interceptor an den Call angehängt. Auf dem Server wird die ID mit dem serverseitigen Interceptor ausgewertet und mit dem laufenden (Call Thread) verknüpft.

 

[Gast2]

Das Prinzip ist genau so richtig ok. Woher soll der Server denn sonst den Zusammenhang zur Session, die ja vom Client gepflegt wird, kennen und mit dem Call in Verbindung bringen. Läuft doch in HTTP auch so, nur dass du es nicht mitbekommst (url rewriting oder cookies).
Du kannst aber die Schnittstelle von diesen Metainformationen frei halten, wie es z.B. auch JAAS macht:
Der Client pflegt die ID und deren Lifycycle. Bei jedem Call wird die ID über eine clientseitigen Interceptor an den Call angehängt. Auf dem Server wird die ID mit dem serverseitigen Interceptor ausgewertet und mit dem laufenden (Call Thread) verknüpft.

Ok undeutlich ausgedrückt ich finds doof dass der Programmierer selber die ID mitgeben muss, die Info sollte automatisch übergeben werden.
Ja so einen clientseitigen Interceptor such ich noch. Wo muss ich den genau einhängen?

Zur ID Generierung passiert die auf dem Client oder Server? Ich dachte auf dem Server und der Client holt sich einmailig diese ID und hält diese.

Ja ich hab jetzt den ganzen ThreadLocal usw. selbst gemacht, da ich die weld Klassen nicht benutzen kann. Ich fand auch den Context nicht den du gemeint hast.

Außerdem weiß ich immer noch nicht so recht wie den akutellen User in meinen Context bekomme.

 

[FArt]

Ich habe mir Weld noch nicht näher angesehen, würde aber davon ausgehen, dass vieles deiner Arbeit dort schon als API zur Verfügung steht.

 

[Gast2]

Ich habe mir Weld noch nicht näher angesehen, würde aber davon ausgehen, dass vieles deiner Arbeit dort schon als API zur Verfügung steht.

Achso okay dachte du kennst es näher.

Ja aber wie gesagt stehen die Contexte mir gar nicht zu Verfügung.

Weißt du wo oder wie ich den Interceptor auf der clientseite einhänge?

grad sieht der Remote aufruf ja so aus: lookup und dann aufruf.

	public Set<Angebot> getAngebote()  {
		return angebotRemoteService.getAngebote(sessionId);
	}

 

[FArt]

Das letzte mal habe ich das im JBoss 5 gemacht, ich glaube das ging so:. man konnte den Client-Interceptor-Stack mit der Annotation @RemoteBinding und dem Attribut interceptorStack konfigurieren.
Die Konfiguration definiert über AOP den Interceptorstack. Man kann seinen eigenen Stack von einem vorhandenen ableiten und dann den eigenen Interceptor dazu hängen. Die eigene Konfiguration kann man zu den anderen im JBoss dazu legen, aber man kann sie auch mit der Applikation deployen.

 

[Gast2]

Das letzte mal habe ich das im JBoss 5 gemacht, ich glaube das ging so:. man konnte den Client-Interceptor-Stack mit der Annotation @RemoteBinding und dem Attribut interceptorStack konfigurieren.
Die Konfiguration definiert über AOP den Interceptorstack. Man kann seinen eigenen Stack von einem vorhandenen ableiten und dann den eigenen Interceptor dazu hängen. Die eigene Konfiguration kann man zu den anderen im JBoss dazu legen, aber man kann sie auch mit der Applikation deployen.

Ja ich hab grad sowas ähnliches gelesen aber das kapier ich grad nicht so ganz^^...

Da liegt der Interceptor doch auf dem Server oder? Wie komme ich dann an die Client-Infos dran? Irgendwo habe ich ein Denkfehler im Ablauf.

EDIT: Kann ich wirklich die SessionID mitgeben?

zurzeit sieht mein Remote Interface so aus

... getAngebote(String sessionID)

und nachher kann ich die Session ID weglassen werden und die komplette Signatur des Interfaces ändern??

getAngebote()

Ich kapiere nicht wie der Interceptor nun die ID an den Server geben soll? Der brauch irgendein Context sowie den HttpSessionContext oder sowas?

 

[FArt]

Ja. Das Interface muss dieses Informationen nicht liefern. Sonst müsstest du ja auch immer den Principal mitliefern.

Du bekommst im Interceptor ein Invocation Objekt mit den Metadaten des Calls. Die kannst du dann einfach anreichern und später wieder auslesen.

Die Konfiguration des Interceptors ist auf der serverseite. Realisiert wird der Interceptor Stack aber über den Bean Stub auf der clientseite.

 

[Gast2]

Ja. Das Interface muss dieses Informationen nicht liefern. Sonst müsstest du ja auch immer den Principal mitliefern.

Du bekommst im Interceptor ein Invocation Objekt mit den Metadaten des Calls. Die kannst du dann einfach anreichern und später wieder auslesen.

Ok das klingt gut.

Die Konfiguration des Interceptors ist auf der serverseite. Realisiert wird der Interceptor Stack aber über den Bean Stub auf der clientseite.

Wenn du dein Beispiel noch hast, kannst es ja mal bereitstellen wenn nicht all zu geheim ist ...
Ich such mal im Netz nach einem Beispiel.

Hier mal was ich bis jetzt versucht habe:

@Interceptor
public class ClientSessionInterceptor implements Serializable {
 
     private static final long serialVersionUID = 1L;
 
     private Object sessionId = "test";
     
     
     @AroundInvoke
     public Object injectSessionId(Invocation invocation) throws Throwable {
          invocation.getMetaData().addMetaData("sessionId", "sessionId", sessionId);
          return invocation.invokeNext();
     }
 
}

@Interceptor
public class SessionContextInterceptor implements Serializable {

    /**
     * 
     */
    private static final long serialVersionUID = 6606220960433411332L;

    @AroundInvoke
    public Object injectMap(InvocationContext ic, Invocation invocation) throws Exception {
        String sessionId = invocation.getMetaData("sessionId", "sessionId").toString();
        Map<String, Object> sessionContextMap = SessionRegistry.getSessionContextMap(sessionId);

    }

}

@Stateful
@Interceptors(SessionContextInterceptor .class)
@RemoteBinding(interceptorStack="ClientSessionInterceptor")
public class AngebotRemoteServiceImpl implements AngebotRemoteService {

Bekomm ich aber die Fehlermeldung

15:04:45,840 ERROR 
[org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: 
name=vfs:///D:/JBoss/jboss-6.0.0.Final/server/default/deploy/xPP_Prototyp.war_WeldBootstrapBean state=Create: org.jboss.weld.exceptions.DeploymentException: WELD-000069 An interceptor must 
have at least one binding, but client.ClientSessionInterceptor has none

 

[Gast2]

Ah das AOP fehlt noch:

Die Konfiguration definiert über AOP den Interceptorstack. Man kann seinen eigenen Stack von einem vorhandenen ableiten und dann den eigenen Interceptor dazu hängen.

Mhm ???:L

aber man kann sie auch mit der Applikation deployen.

Im META-INF Ordner jboss-aop.xml anlegen oder?

 

[FArt]

Wenn ich mich recht erinnere, eine Archiv mit der Endung aop und einem passenden Deskriptor im META-INF.

 

[Gast2]

Wenn ich mich recht erinnere, eine Archiv mit der Endung aop und einem passenden Deskriptor im META-INF.

Klappt des überhaupt so wie ich das mache mit Annotations, weil ich find nur Beispiele wo implements gemacht wird.

Und im ServerInterceptor gebe ich 2 Argumente mit geht sowas überhaupt?

 

[Gast2]

Mal eine andere Idee. Wenn ich ein eigenes LoginModul oder mich in einer einhänge und dort dann im Principal eine UUID erstelle. Oder im SessionContext die reinspeichere oder so etwas??

EDIT: Sie UUID sollte meines Wissens nach auf dem Server erstellt werden. Wenn der Client sich einen InitalContext holt sich eine UUID zurück liefern lässt diese in die Props reinschreibst und dann mit JAAS anmeldet. Diese kann man dann doch immer auslesen. Aber wie kann man in der contextData reinschreiben?

    @Resource
    private SessionContext sessionContext;

    @AroundInvoke
    public Object injectMap(InvocationContext ic) throws Exception {
    	System.out.println(sessionContext.getCallerPrincipal());
    	System.out.println(sessionContext.getContextData());

 

[FArt]

Blätter mal ein paar Seiten zurück. Da hatte ich schon erwähnt, dass man die Prinzipalinformationen mit einer Sessioninformationen anreichern könnte ;-)
Wo die SessionID erzeugt wird, sollte egal sein. Ich würde sagen das ist Geschmackssache.

 

[Gast2]

Blätter mal ein paar Seiten zurück. Da hatte ich schon erwähnt, dass man die Prinzipalinformationen mit einer Sessioninformationen anreichern könnte ;-)
Wo die SessionID erzeugt wird, sollte egal sein. Ich würde sagen das ist Geschmackssache.

haha okay =), aber die Frage ist wie ist es m besten/schönsten .

Ich dachte mal ein eigenes LoginModul, aber das wird nie aufgerufen =(
Bsp:

[XML]
<application-policy name = "test">
<authentication>
<login-module
code="login.TestLogin"
flag = "required">
<module-option
name="usersProperties">
props/prototyp-users.properties
</module-option>
<module-option
name="rolesProperties">
props/prototyp-roles.properties
</module-option>
<module-option name="principalClass">login.MyPrincipal</module-option>
</login-module>
</authentication>
</application-policy>
[/XML]

public class TestLogin extends UsersRolesLoginModule{

	@Override
	protected Principal getIdentity() {
		System.out.println(super.getIdentity());
		return super.getIdentity();
	}
	@Override
	protected Principal createIdentity(String name) throws Exception {
		System.out.println("createIdentity");
		return new MyPrincipal(UUID.randomUUID().toString(), name);
	}	
}

Oder gibt es eine besser Möglichkeit?Und ich überseh gerade deinen Post?

    @Resource
    private SessionContext sessionContext;

    @AroundInvoke
    public Object injectMap(InvocationContext ic) throws Exception {
    	System.out.println(sessionContext.getCallerPrincipal()); ist immer SimplePrinicpal WARUM=??

EDIT:
ähm lol?
Custom Principal class problem. SessionContext always return | PicketBox | JBoss Community

Anscheinend gefixed aber
https://issues.jboss.org/browse/JBAS-8427

EDIT EDIT: Meine 2te Idee wäre gewesen Die einvirmoment vond em InitalContext auszulesen aber ich finde keine passende Methode daüfr wie ich da hinkomm.
D.h auf ClientSeite einfach eine Prop setzen die auswerten, aber wie komme ich da hin?

 

[Gast2]

Sorry aber ich versteh nicht wie Sachen an das Principal oder an den EJBContext hängen kann

auf der clientseite mit prop.put("test","test"); gehts nicht, wird zumindest hier gesagt

Wie kann ich Clientinformationen an SessionBean weitergeben [Archiv] - Entwickler-Forum

aber wie hast du es dann gemeint?


EDIT: Spricht was dagegen

SecurityContextAssociation.getSecurityContext().getUtil().getCredential()

zu nehmen?

 

[TheDarkRose]

EDIT: Spricht was dagegen

SecurityContextAssociation.getSecurityContext().getUtil().getCredential()

zu nehmen?

Eigentlich nicht, ist halt nur JBoss spezifisch. Theorpraktisch könntest dir auch eine eigene InitialContextFactory schreiben, wenn sichs was bringt.

 

[Gast2]

Ja ein eigenes Principal wäre optimal gewesen aber irgendwie bekomme ich das ja nicht zum laufen siehe oben.

Vielleicht kann mir fart noch genauer sagen wie er die Principal mit infos anreichern würde

 

[FArt]

Ja ein eigenes Principal wäre optimal gewesen aber irgendwie bekomme ich das ja nicht zum laufen siehe oben.

Vielleicht kann mir fart noch genauer sagen wie er die Principal mit infos anreichern würde

Ist schon etwas länger her und ich versuche mich zu erinnern: ich glaube wir hatten ein eigenes LoginModul und eine eine eigenen Prinicipal-Implementierung. Befüllen und auslesen passierte in den jeweiligen Interceptoren (Client und Server). Die eigentlichen Credentials wurden dann vom Loginmodul ausgewertet.
Wichtig dabei war nur, dass der eigenen Interceptor nach dem SecurityInterceptor des JBoss drankommt, sonst sind die Objekte noch nicht initialisiert ;-)

 

[Gast2]

Ist schon etwas länger her und ich versuche mich zu erinnern: ich glaube wir hatten ein eigenes LoginModul und eine eine eigenen Prinicipal-Implementierung. Befüllen und auslesen passierte in den jeweiligen Interceptoren (Client und Server). Die eigentlichen Credentials wurden dann vom Loginmodul ausgewertet.
Wichtig dabei war nur, dass der eigenen Interceptor nach dem SecurityInterceptor des JBoss drankommt, sonst sind die Objekte noch nicht initialisiert ;-)

Kanns so kompliziert brauch ich es gar nicht =). Es würde schon reichen wenn die eigene Prinicipal-Implementierung mit LoginModul funktioniert dann wäre alles gelöst ...Aber wie oben klappes es einfach nicht =(

 

[Gast2]

Man muss tatsächlich ein SimplePrincipal Echo einführen damit es tut. Sieht auch nach workaround aus ...

	@Override
	protected Group[] getRoleSets() throws LoginException {
		SimpleGroup rolesGroup = new SimpleGroup("Roles");
		rolesGroup.addMember(new SimplePrincipal("Echo"));
		Group callerPrincipal = new SimpleGroup("CallerPrincipal");
		callerPrincipal.addMember(this.getIdentity());
		Group[] newgroups = { rolesGroup, callerPrincipal };
		return newgroups;
	}

Danke alle nochmal für die Hilfe =)

 

[FArt]

Sieht auch nach workaround aus ...

Ja, über den Principal ist es vermutlich ... ein Workaround, wenn auch m.E. vertretbar.
Einfach gut dokumentieren