[JBoss JIRA] Created: (JBAS-3445) Testcase for UTF-8 support with FORM Authentication
by Anil Saldhana (JIRA)
Testcase for UTF-8 support with FORM Authentication
---------------------------------------------------
Key: JBAS-3445
URL: http://jira.jboss.com/jira/browse/JBAS-3445
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-4.0.4.GA
Reporter: Anil Saldhana
Assigned To: Anil Saldhana
Fix For: JBossAS-4.0.6.CR1
User says:
========================================================
I have run into as well using JBoss 4.0.3SP1 (and 4.0.4GA).
In my Web Applications, I can login with English usernames and passwords just fine.
But when I try to login with a Russian or Chineese username, the login always fails.
>From the tracing I've done, it seems the username is getting converted to ISO-8859-1, and that's why it's failing.
I've done all the "standard" things to make our pages UTF-8, and this does work on every page except the login page. Something about "j_security_check" is ignoring UTF-8 and forcing a conversion to "ISO-8859-1".
=========================================================
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 7 months
[JBoss JIRA] Created: (JBAS-3400) JaasSecurityManagerService can show security provider/JCA algorithm information
by Anil Saldhana (JIRA)
JaasSecurityManagerService can show security provider/JCA algorithm information
-------------------------------------------------------------------------------
Key: JBAS-3400
URL: http://jira.jboss.com/jira/browse/JBAS-3400
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-4.0.4.GA
Reporter: Anil Saldhana
Assigned To: Sohil Shah
Priority: Optional
Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP2
It may be useful to determine the security providers and the various JCA algorithms installed in the JDK.
So, add two methods to the JaasSecurityManagerService as follows:
- showProviders()
- getAlgorithm(String serviceName)
If the serviceName is null, show all the possible JCA service names.
Here is a partial tested code, that you may want to adapt:
======================================================================================
import java.security.*;
import java.util.*;
public class A
{
public static void main(String[] args)
{
Provider[] providers = Security.getProviders();
for(int i = 0; i < providers.length; i++)
{
System.out.println("Provider="+providers[i].toString());
}
System.out.println("Printing JCA Algorithm Information");
printJCAAlgorithm("Cipher");
printJCAAlgorithm("Signature");
printJCAAlgorithm("KeyFactory");
printJCAAlgorithm("SecretKeyFactory");
printJCAAlgorithm("AlgorithmParameters");
printJCAAlgorithm("MessageDigest");
printJCAAlgorithm("Mac");
}
private static void printJCAAlgorithm(String sName)
{
System.out.println("Printing "+sName);
Set md2 = Security.getAlgorithms(sName);
System.out.println(sName + " set length="+md2.size());
Iterator md2iter = md2.iterator();
while(md2iter.hasNext())
{
System.out.println(md2iter.next().toString());
}
}
}
====================================================================================
The output is:
asaldhana~/testSecurity>java -cp . -Djava.security.manager A
Provider=SUN version 1.5
Provider=SunRsaSign version 1.5
Provider=SunJSSE version 1.5
Provider=SunJCE version 1.5
Provider=SunJGSS version 1.0
Provider=SunSASL version 1.5
Printing JCA Algorithm Information
Printing Cipher
Cipher set length=13
ARCFOUR
PBEWITHSHA1ANDDESEDE
DESEDEWRAP
PBEWITHMD5ANDTRIPLEDES
DESEDE
RSA
AESWRAP
AES
PBEWITHMD5ANDDES
BLOWFISH
DES
RC2
PBEWITHSHA1ANDRC2_40
Printing Signature
Signature set length=9
SHA256WITHRSA
NONEWITHDSA
....
Make the changes in HEAD. I will port it to Branch_4_0 and Branch_3_2
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 7 months
[JBoss JIRA] Created: (JBAS-3613) failing test in org.jboss.test.iiop.test.ParameterPassingStressTestCase
by Dimitris Andreadis (JIRA)
failing test in org.jboss.test.iiop.test.ParameterPassingStressTestCase
-----------------------------------------------------------------------
Key: JBAS-3613
URL: http://jira.jboss.com/jira/browse/JBAS-3613
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: IIOP service, Test Suite
Environment: Java Version 1.5.0_05
Java Vendor Sun Microsystems Inc.
Java VM Name Java HotSpot(TM) Server VM
Java VM Version 1.5.0_05-b05
Java VM Info mixed mode
OS Name Linux
OS Version 2.6.9-34.0.2.ELsmp
OS Arch i386
Reporter: Dimitris Andreadis
Assigned To: Francisco Reverbel
Fix For: JBossAS-4.0.5.GA
test_getException Error
Invalid indirection to offset 1704
java.io.IOException: Invalid indirection to offset 1704
at com.sun.corba.se.impl.io.IIOPInputStream$ActiveRecursionManager.getObject(IIOPInputStream.java:2684)
at com.sun.corba.se.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2218)
at com.sun.corba.se.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1221)
at com.sun.corba.se.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:400)
at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:327)
at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2438)
at com.sun.corba.se.impl.io.ValueHandlerImpl.read_Array(ValueHandlerImpl.java:756)
at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:325)
at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2438)
at com.sun.corba.se.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:1989)
at com.sun.corba.se.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2213)
at com.sun.corba.se.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1221)
at com.sun.corba.se.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:400)
at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:327)
at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2310)
at org.jacorb.orb.Any.read_value(Any.java:816)
at org.jacorb.orb.CDRInputStream.read_any(CDRInputStream.java:673)
at com.sun.corba.se.impl.javax.rmi.CORBA.Util.readAny(Util.java:401)
at javax.rmi.CORBA.Util.readAny(Util.java:92)
at org.jboss.iiop.rmi.marshal.CDRStream$ObjectReader.read(CDRStream.java:618)
at org.jboss.iiop.rmi.marshal.strategy.StubStrategy.readRetval(StubStrategy.java:226)
at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:128)
at org.jboss.test.iiop.interfaces._StatelessSession_Stub.getException(Unknown Source)
at org.jboss.test.iiop.test.ParameterPassingStressTestCase.test_getException(ParameterPassingStressTestCase.java:355)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 7 months
[JBoss JIRA] Created: (JGRP-446) When using an extremely simple protocol stack the app will respond with a NullPointerException.
by Anders Persson (JIRA)
When using an extremely simple protocol stack the app will respond with a NullPointerException.
-----------------------------------------------------------------------------------------------
Key: JGRP-446
URL: http://jira.jboss.com/jira/browse/JGRP-446
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4.1 SP1
Environment: Windows XP
java version "1.5.0_11"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode)
Reporter: Anders Persson
Assigned To: Bela Ban
Priority: Minor
When using an extremely simple protocol stack the app will respond with a NullPointerException. The communication will however work (at least when running all parties on the same machine). The stack used:
<protocol_stacks>
<stack name="standard" description="Multicast stack intended for usage on internal highspeed networks.">
<config>
<UDP mcast_addr="228.15.15.15"
mcast_port="45566"/>
<PING timeout="2000"/>
</config>
</stack>
<stack name="slow" description="Multicast stack intended for usage on external slow connections.">
<config>
<UDP mcast_addr="228.15.15.15"
mcast_port="45567"/>
<PING timeout="2000"/>
</config>
</stack>
</protocol_stacks>
Starting DrawMultiplexer using the stack above will generate the following stack trace
2007-mar-26 16:51:24 org.jgroups.JChannelFactory connect
SEVERE: failed sending SERVICE_UP message
java.lang.NullPointerException
at org.jgroups.mux.Multiplexer.generateServiceView(Multiplexer.java:953)
at org.jgroups.mux.Multiplexer.handleServiceUp(Multiplexer.java:781)
at org.jgroups.mux.Multiplexer.sendServiceUpMessage(Multiplexer.java:224)
at org.jgroups.JChannelFactory.connect(JChannelFactory.java:372)
at org.jgroups.mux.MuxChannel.connect(MuxChannel.java:126)
at org.jgroups.demos.DrawMultiplexer.start(DrawMultiplexer.java:44)
at org.jgroups.demos.DrawMultiplexer.main(DrawMultiplexer.java:29)
I traced the "problem" to be the lack of a pbcast.GMS entry. (You can try it by removing that entry in the conf/stacks.xml file in your distribution.)
Some additional information:
In order to get DrawMultiplexer to "communicate" you will have to start two instances using the stack above. Then press "leave" in the window that pops up as a result of the FIRST instance started. (Don't know the inner workings of the DrawMultiplexer app, I don't have to resort to these kinds of actions to get my own app to communicate.)
The reason I would like to see this fixed is that I don't want to have NullPointerExceptions in the log file when deploying this at the customer.
The reason for my very simple protocol is that we intend to use JGroups in a configuration where one server pumps out data in a stream to a varying number of clients and we don't care if the data was received correctly or not since the stream of data is repeated every six seconds.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 7 months