[JBoss Web Development] New message: "jboss4.2.3 problem with encoding characters in HTML"
by Abhishek Bhardwaj
JBoss development,
A new message was posted in the thread "jboss4.2.3 problem with encoding characters in HTML":
http://community.jboss.org/message/524287#524287
Author : Abhishek Bhardwaj
Profile : http://community.jboss.org/people/abhishekbhardwaj
Message:
--------------------------------------------------------------
Hi All,
I have a java web developer using Jboss as my Application server.
My application deals with different languages like english,Italian,german etc.There is a Report Attached to my thread relating to my problem.
When i open the page directly in browser(IE or Mozzila), all the characters are coming properly.But the moment i use it through my server(JBOSS),
i.e for testing put the uploaded page in web-inf of any of ur application and try accessing it through URL, few special characters are not coming properly.
I have used proper Encding technique :
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
still it's not working when i access the page through Jboss.But the same works fine in Tomcat.
I need help .Please do help me.waiting for reply
Regards,
Abhishek
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524287#524287
14 years, 3 months
[Security Development] Document updated/added: "PicketBox Authorization"
by ANIL SALDHANA
JBoss development,
The document "PicketBox Authorization", was updated Feb 4, 2010
by ANIL SALDHANA.
To view the document, visit:
http://community.jboss.org/docs/DOC-14747#cf
Document:
--------------------------------------------------------------
*PicketBox* (Formerly JBoss Security) has support for authorization or access control
*Types of Authorization*
1. Coarse Grained
2. Fine Grained including Instance Based Authorization
*Coarse Grained Authorization*
You can use the PicketBoxAuthorizationModule to provide access control to your java application. Please see the example below.
*Fine Grained Authorization*
1. http://community.jboss.org/docs/DOC-10840
2. http://server.dzone.com/articles/security-features-jboss-510-3
Sample Code for Coarse Grained Authorization
import java.security.Principal;
import java.util.HashMap;
import java.util.Map;
import javax.security.auth.Subject;
import org.jboss.security.AuthenticationManager;
import org.jboss.security.AuthorizationManager;
import org.jboss.security.authorization.AuthorizationContext;
import org.jboss.security.authorization.Resource;
import org.jboss.security.authorization.ResourceType;
import org.picketbox.config.PicketBoxConfiguration;
import org.picketbox.factories.SecurityFactory;
//Variables
private final String securityDomainName = "test";
private final String configFile = "config/authorization.conf";
public void testValidAuthorization() throws Exception
{
SecurityFactory.prepare();
try
{
PicketBoxConfiguration idtrustConfig = new PicketBoxConfiguration();
idtrustConfig.load(configFile);
AuthenticationManager am = SecurityFactory.getAuthenticationManager(securityDomainName);
assertNotNull(am);
Subject subject = new Subject();
Principal principal = getPrincipal("anil");
Object credential = new String("pass");
boolean result = am.isValid(principal, credential, subject);
assertTrue("Valid Auth", result);
assertTrue("Subject has principals", subject.getPrincipals().size() > 0);
AuthorizationManager authzM = SecurityFactory.getAuthorizationManager(securityDomainName);
assertNotNull(authzM);
Resource resource = getResource();
int decision = authzM.authorize(resource, subject);
assertTrue(decision == AuthorizationContext.PERMIT);
}
finally
{
SecurityFactory.release();
}
}
public void testInvalidAuthorization() throws Exception
{
SecurityFactory.prepare();
try
{
PicketBoxConfiguration idtrustConfig = new PicketBoxConfiguration();
idtrustConfig.load(configFile);
AuthenticationManager am = SecurityFactory.getAuthenticationManager(securityDomainName);
assertNotNull(am);
Subject subject = new Subject();
Principal principal = getPrincipal("anil");
Object credential = new String("pass");
boolean result = am.isValid(principal, credential, subject);
assertTrue("Valid Auth", result);
assertTrue("Subject has principals", subject.getPrincipals().size() > 0);
AuthorizationManager authzM = SecurityFactory.getAuthorizationManager(securityDomainName);
assertNotNull(authzM);
Resource resource = getResource();
int decision = authzM.authorize(resource, subject);
assertTrue(decision == AuthorizationContext.PERMIT);
}
finally
{
SecurityFactory.release();
}
}
private Principal getPrincipal(final String name)
{
return new Principal()
{
public String getName()
{
return name;
}
};
}
private Resource getResource()
{
return new Resource()
{
public ResourceType getLayer()
{
return ResourceType.IDTRUST;
}
public Map<String, Object> getMap()
{
return new HashMap<String,Object>();
}
};
}
As usual we have a SecurityFactory.prepare() and SecurityFactory.release() in a try/finally structure to initialize and release picketbox.
The authorization.conf looks as follows:
<?xml version='1.0'?>
<policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:jboss:security-config:5.0"
xmlns="urn:jboss:security-config:5.0"
xmlns:jbxb="urn:jboss:security-config:5.0">
<application-policy name = "test">
<authentication>
<login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option name = "name">1.1</module-option>
<module-option name = "succeed">true</module-option>
<module-option name = "throwEx">false</module-option>
</login-module>
</authentication>
<authorization>
<policy-module
code="org.picketbox.plugins.authorization.PicketBoxAuthorizationModule">
<module-option name="roles">validuser</module-option>
</policy-module>
</authorization>
</application-policy>
</policy>
In this case, PicketBoxAuthorizationModule is configured with a comma separated list of roles (validuser).
--------------------------------------------------------------
14 years, 3 months
[Security Development] Document updated/added: "PicketBox Authentication"
by ANIL SALDHANA
JBoss development,
The document "PicketBox Authentication", was updated Feb 4, 2010
by ANIL SALDHANA.
To view the document, visit:
http://community.jboss.org/docs/DOC-14745#cf
Document:
--------------------------------------------------------------
PicketBox (formely JBoss Security) provides JAAS based authentication facilities for Java applications.
*
*
*Pre-requisites*
* If you are running in JBoss Application Server v5.0 and beyond, the dependencies of PicketBox are available. In this case, you only need to download the PicketBox core libraries.
* If you are running in a non JBoss AS 5+ environment, then you will need to download some dependencies for PicketBox apart from the core libraries.
*Authentication*
I
t is based on JAAS, available as part of the JDK.
We provide simple file based authentication, Database based authentication and LDAP based authentication. Choose the login module that is suitable for you.
* http://community.jboss.org/docs/DOC-11251
* http://community.jboss.org/docs/DOC-11253
* http://community.jboss.org/docs/DOC-9511
* http://community.jboss.org/docs/DOC-12510
*Sample Code*
//Imports
import java.security.Principal;
import java.util.HashMap;
import java.util.Map;
import javax.security.auth.Subject;
import org.jboss.security.AuthenticationManager;
import org.jboss.security.AuthorizationManager;
import org.jboss.security.authorization.AuthorizationContext;
import org.jboss.security.authorization.Resource;
import org.jboss.security.authorization.ResourceType;
import org.picketbox.config.PicketBoxConfiguration;
import org.picketbox.factories.SecurityFactory;
//Arbitrary Method for authentication
private static void testAuthentication()
{
SecurityFactory.prepare();
try
{
String configFile = "config/authentication.conf";
PicketBoxConfiguration idtrustConfig = new PicketBoxConfiguration();
idtrustConfig.load(configFile);
AuthenticationManager am = SecurityFactory.getAuthenticationManager(securityDomainName);
if(am == null)
throw new RuntimeException("Authentication Manager is null");
Subject subject = new Subject();
Principal principal = getPrincipal("anil");
Object credential = new String("pass");
boolean result = am.isValid(principal, credential);
if(result == false)
throw new RuntimeException("Authentication Failed");
result = am.isValid(principal, credential, subject);
if(result == false)
throw new RuntimeException("Authentication Failed");
if(subject.getPrincipals().size() < 1)
throw new RuntimeException("Subject has zero principals");
System.out.println("Authentication Successful");
}
finally
{
SecurityFactory.release();
}
}
Let us take a look at authentication.conf
<?xml version='1.0'?>
<policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:jboss:security-config:5.0"
xmlns="urn:jboss:security-config:5.0"
xmlns:jbxb="urn:jboss:security-config:5.0">
<application-policy name = "test">
<authentication>
<login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
</login-module>
</authentication>
</application-policy>
</policy>
In this example, we had two properties files:
defaultUsers.properties
anil=pass
defaultRoles.properties
anil=validuser
This example was very simple. It made use of a file based login module. In your enterprise application, either the ldap or db based login module is recommended.
--------------------------------------------------------------
14 years, 3 months
[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"
by Kabir Khan
JBoss development,
A new message was posted in the thread "Pluggable dependency resolver":
http://community.jboss.org/message/524239#524239
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
I got AS trunk started with the indexing dependency resolver, unfortunately I did not see any difference in startup speed worth mentioning :-(
So, although we only try to increment the contexts that have actually had a dependency resolved, at the moment there is a lot of work going into determining what those contexts are. Maybe too much?
An overview of what I have so far is probably best described with an example. I deploy
<bean name="Bean" class="...">
<property name="prop"><inject bean="Other"/></property>
</bean>
Since this is an explicit dependency on a name which is required in the CONFIGURED state and Other reaches the INSTALLED state, this is recorded in the NameDependencyResolverMatcher under
[INSTALLED->["Other"->{Context[name="Bean"]}]
(Read as when a bean called "Other" reaches the Installed state, the Context named Bean is a candidate for injection)
We then try to push Bean as far through the states as we can, in this case it will stop in the INSTANTIATED state since Other is not available yet when we try to resolve the dependencies to enter Configured.
Now if we deploy
<bean name="Other" class="…"/>
We push this through the states. There is a stateIncremented(ControllerContext) method in the resolver called by the controller whenever a context has its state incremented which calls through to all the dependency resolver matchers. For Other in PRE_INSTALL, …, START nothing is found in the matchers so we just keep on moving Other through the lifecycle. Once stateIncremented(ControllerContext) is called for Other when it hits the INSTALLED state we then check all the dependency resolver matchers. We hit the NameDepedencyResolverMatcher and for INSTALLED we find
["Other"->{Context[name="Bean"]}]
We then look up "Other" in this map and find
{Context[name="Bean"]}
in other words the context called Bean has been waiting for Other to reach the INSTALLED phase, we then check that Bean has its other dependencies resolved and then attempt to push it through the states as before.
I have not tried profiling anything yet, but for simple dependencies like the one above I think the above mechanism should be fast. However, there are a few other factors that could well slow it all down.
====== Contextual Injection (and Callbacks) =========
If we first deploy
<bean name="Bean" class="...">
<property name="prop"><inject/></property>
</bean>
where the type of the prop property is 'interface SomeInterface'. This becomes a ContextualInjectionDependencyItem, and is recorded in ContextualInjectionDependencyResolverMatcher as
[INSTALLED->[[interface SomeInterface]->{Context[name="Bean"]}]
As before Bean is moved to the INSTANTIATED phase.
Now we deploy
<bean name="Bean" class="SomeClass"/>
where SomeClass somewhere in its inheritance hierarchy has SomeInterface as a parent. When installing Bean, each time its state is incremented it checks the matchers for matching contexts. It will find nothing in NameDependencyResolverMatcher nor in ContextualInjectionDependencyMatcher for PRE_INSTALL, …,START. When it gets to INSTALLED, again it finds nothing in NameDependencyResolverMatcher, but when it hits ContextualInjectionDependencyMatcher it finds this for INSTALLED
[interface SomeInterface]->{Context[name="Bean"]}
Now it checks if SomeClass is there, nothing. Then do the same for all the superclasses and interfaces until it finally finds the Bean Context under SomeInterface. We then check Bean's other dependencies and push it through the remaining states.
I am not sure how extensively contextual injection is used in the AS, but the point here is that if contextual injection is used *at all* and we have contexts registered as waiting for a few other states, whenever other contexts reach one of those states we have to do all the work of looking up all the superclasses/interfaces to see if any of the waiting contexts can be removed.
Also, this work is duplicated since we also have a CallbackDependencyResolverMatcher which effectively does exactly the same but for CallbackDependencyItems.
====== Scoping =======
We only record the dependencies in the matchers for the controller into which the context owning the dependency was installed. If a context has its state incremented, there might be contexts with dependencies on it waiting in one of the child controllers. So the stateIncremented(ControllerContext) method ends up calling stateIncremented(ControllerContext) on all the child controller resolvers as well, which in turn will invoke all the matchers for each child controller.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524239#524239
14 years, 3 months
[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"
by Kabir Khan
JBoss development,
A new message was posted in the thread "Pluggable dependency resolver":
http://community.jboss.org/message/524183#524183
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
Apart from aop-mc-int since its tests are more complex than the others, I have got the tests running for all other modules in both modes in the branch. I had to adjust how dependency/OnDemandUnitTestCase and jmx-mc-int/NewOnDemandDependencyTest compare the expected install orders since the ordering with the new resolver is slightly different.
Also, I excluded the BadDependencyInfoTestCase from the indexing dependency resolver run since no matter how hard I try I just can't figure out what this test does :-) anyway it seems to depend on implementation details for the standard dependency resolver, so we will probably need a similar but different test for the indexing dependency resolver.
I tried booting up AS with the indexing dependency resolver enabled yesterday and it fell over, so I need to figure out why and try to test that as well as address the points in my previous post.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524183#524183
14 years, 3 months
[JBoss Microcontainer Development] New message: "Using MetaDataRetrievalFactory is missing addition"
by Ales Justin
JBoss development,
A new message was posted in the thread "Using MetaDataRetrievalFactory is missing addition":
http://community.jboss.org/message/524180#524180
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
When we use an explicit MetaDataRetrievalFactory to create MDRetrieval for scope level,
we never actually add the newly created retrieval to repository.
This results in retrieval override, since the factory is invoked for every lookup.
Just follow PreInstallAction and its MD::addMetaData invocation.
AbstractKernelScopeInfo
public void addMetaData(MutableMetaDataRepository repository, ControllerContext context)
{
this.repository = repository;
ScopeKey scope = getMutableScope();
MetaDataRetrieval retrieval = repository.getMetaDataRetrieval(scope); // HERE -- factory creates it
MutableMetaDataLoader mutable;
if (retrieval == null)
{
mutable = initMutableMetaDataRetrieval(repository, context, scope);
repository.addMetaDataRetrieval(mutable);
addedScopes.add(scope);
}
else
{
mutable = getMutableMetaDataLoader(retrieval);
}
if (mutable == null)
{
log.warn("MetaData context is not mutable: " + retrieval + " for " + context.toShortString());
return;
}
updateMetaData(repository, context, mutable, true);
}
BasicMetaDataRepository
public MetaDataRetrieval getMetaDataRetrieval(ScopeKey key)
{
MetaDataRetrieval result = retrievals.get(key);
if (result != null)
return result;
// Is this a single level?
Collection<Scope> scopes = key.getScopes();
if (scopes.size() != 1)
return null;
// See if we have a factory
Scope scope = scopes.iterator().next();
ScopeLevel scopeLevel = scope.getScopeLevel();
MetaDataRetrievalFactory factory = getMetaDataRetrievalFactory(scopeLevel);
if (factory == null)
return null;
// We have a factory, use it
return factory.getMetaDataRetrieval(scope); // HERE -- created, but never added
}
I currently fixed it by adding the newly created retrieval in the MDRFactory itself.
But what should be the right place to do it? Or how?
Since AbstractKernelScopeInfo only cares about getting the MDRetrieval.
Perhaps a getOrCreateAndAdd method on MutableMetaDataRepository?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524180#524180
14 years, 3 months