Ted Bell

Hi all,

Our customer has raised a concern with our web application with the following scenario:

1. User logs in and uses application.
2. User types in new address in browser and navigates off our site without explicitly logging out.
3. User hits 'Back' button and is returned to our application with the original session still active.

I have seen many articles and postings related to controlling the browser cache and redirecting the user to the login when the session has expired or been invalidated, but nothing involving this scenario in which the session is still active. I'm not sure how to control this since we have a valid session. I am researching use of the 'Referer' header to see if this might be a reliable way to test if a request came from within our application, but I suspect this is far from fool-proof.

Anyone come across similar requirements from a customer, or have experience with using 'Referer' to control this?

Thanks for any advice.

Hi all,

We recently upgraded from WebLogic Server 8.1 to 8.1 SP4. This has an associated upgrade in the JDK from (for us) 1.4.1_07 to 1.4.2_05 (bundled with SP4). Since the upgrade, we have had some issues making a particular web service call over SSL. The application is deployed as a web application deployed in an EAR file. The web service uses a self-signed certificate (one way), and was working fine prior to the upgrade. We use (in a separate module of the application) an nCipher device and software to encrypt sensitive data. This portion is actually working correctly, but the outbound web service call (having nothing to do with nCipher) is now failing since the upgrade. The precise error is:

java.security.InvalidKeyException: In nCImportedKey with key class - javax.crypto.spec.SecretKeySpec, algorithm RC4

A portion of the stack trace reveals something puzzling (to me at least):


at com.ncipher.provider.nCImportedKey.<init>(nCImportedKey.java:74)
at com.ncipher.provider.Utils.getKeySize(Utils.java:500)
at com.ncipher.provider.nCBlockCipher.engineGetKeySize(nCBlockCipher.java:485)
at javax.crypto.Cipher.init(DashoA6275)
at com.certicom.tls.provider.Cipher.init(Unknown Source)
at com.certicom.tls.ciphersuite.SecurityParameters.createWriteCipher(Unknown Source)

Notice that at some point the 'certicom' libraries/provider (bundled with WebLogic) give way to the ncipher classes (which again should not be used for the HTTPS call, only to encrypt customer data). Thinking this is might be an issue with the security providers in the java.security file. Before the upgrade (1.4.1_07):

security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider
security.provider.3=com.sun.rsajca.Provider
security.provider.4=cryptix.provider.Cryptix
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=com.ncipher.provider.km.nCipherKM
security.provider.7=sun.security.jgss.SunProvider

After the upgrade, under JDK 1.4.2_05:

security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider
security.provider.3=com.sun.rsajca.Provider
security.provider.4=cryptix.provider.Cryptix
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.ncipher.provider.km.nCipherKM

The nCipher provider was moved to the bottom of the list as a troubleshooting step in attempts to block that provider for being used at the wrong time. No changes made thus far have had any effect. WebLogic support have suggested to remove the "com.sun.crypto.provider.SunJCE" entry from the security file, which we will be doing tomorrow.

We tried the solution described in CR206178, which was to move all the jar files from the /jre/lib/ext folder of JDK 1.4.1 into the /jre/lib/ext of JDK 1.4.2. This had no effect.

Stack trace of error printed to stderr:

java.security.InvalidKeyException: In nCImportedKey with key class - javax.crypto.spec.SecretKeySpec, algorithm RC4
at com.ncipher.provider.nCImportedKey.<init>(nCImportedKey.java:74)
at com.ncipher.provider.Utils.getKeySize(Utils.java:500)
at com.ncipher.provider.nCBlockCipher.engineGetKeySize(nCBlockCipher.java:485)
at javax.crypto.Cipher.init(DashoA6275)
at com.certicom.tls.provider.Cipher.init(Unknown Source)
at com.certicom.tls.ciphersuite.SecurityParameters.createWriteCipher(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.changeCipherSpec(Unknown Source)
at com.certicom.tls.record.handshake.ClientStateReceivedCertificate.handle(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessage(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(Unknown Source)
at com.certicom.tls.record.MessageInterpreter.interpretContent(Unknown Source)
at com.certicom.tls.record.MessageInterpreter.decryptMessage(Unknown Source)

Additional trace information from the WLS domain log file:

<Exception during handshake, stack trace follows
java.lang.IllegalStateException: Cipher not initialized
at javax.crypto.Cipher.update(DashoA6275)
at com.certicom.tls.provider.Cipher.update(Unknown Source)
at com.certicom.tls.record.MessageEncryptor.compressEncryptSend(Unknown Source)
at com.certicom.tls.record.MessageEncryptor.compressEncryptSend(Unknown Source)
at com.certicom.tls.record.MessageFragmentor.write(Unknown Source)
at com.certicom.tls.record.WriteHandler.write(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.write(Unknown Source)
at com.certicom.tls.record.handshake.ClientStateReceivedCertificate.handle(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessage(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(Unknown Source)
at com.certicom.tls.record.MessageInterpreter.interpretContent(Unknown Source)
at com.certicom.tls.record.MessageInterpreter.decryptMessage(Unknown Source)
at com.certicom.tls.record.ReadHandler.processRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Unknown Source)
at com.certicom.tls.record.WriteHandler.write(Unknown Source)
at com.certicom.io.OutputSSLIOStreamWrapper.write(Unknown Source)
at com.certicom.net.ssl.HttpsClient.doHandshake(Unknown Source)
at com.certicom.net.ssl.internal.HttpURLConnection.getInputStream(Unknown Source)
at weblogic.webservice.client.https.HttpsURLConnection.getInputStream(HttpsURLConnection.java:228)
at weblogic.webservice.tools.wsdlp.DefinitionFactory.createDefinition(DefinitionFactory.java:106)
at weblogic.webservice.tools.wsdlp.WSDLParser.<init>(WSDLParser.java:76)
at weblogic.webservice.WebServiceFactory.createFromWSDL(WebServiceFactory.java:108)
at weblogic.webservice.core.rpc.ServiceImpl.<init>(ServiceImpl.java:91)
at weblogic.webservice.core.rpc.ServiceImpl.<init>(ServiceImpl.java:66)



<NEW ALERT with Severity: FATAL, Type: 40
java.lang.Exception: New alert stack
at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessage(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(Unknown Source)
at com.certicom.tls.record.MessageInterpreter.interpretContent(Unknown Source)
at com.certicom.tls.record.MessageInterpreter.decryptMessage(Unknown Source)
at com.certicom.tls.record.ReadHandler.processRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Unknown Source)
at com.certicom.tls.record.WriteHandler.write(Unknown Source)
at com.certicom.io.OutputSSLIOStreamWrapper.write(Unknown Source)
at com.certicom.net.ssl.HttpsClient.doHandshake(Unknown Source)
at com.certicom.net.ssl.internal.HttpURLConnection.getInputStream(Unknown Source)
at weblogic.webservice.client.https.HttpsURLConnection.getInputStream(HttpsURLConnection.java:228)
at weblogic.webservice.tools.wsdlp.DefinitionFactory.createDefinition(DefinitionFactory.java:106)
at weblogic.webservice.tools.wsdlp.WSDLParser.<init>(WSDLParser.java:76)
at weblogic.webservice.WebServiceFactory.createFromWSDL(WebServiceFactory.java:108)
at weblogic.webservice.core.rpc.ServiceImpl.<init>(ServiceImpl.java:91)
at weblogic.webservice.core.rpc.ServiceImpl.<init>(ServiceImpl.java:66)


The same web service call made in an environment without the nCipher device and software has no issues. A web service call over HTTPS to a completely different target run outside the WebLogic server (using the same JDK 1.4.2_05) on a server with the nCipher device and software installed also works fine.

Hoping someone might have had a similar problem or be familiar enough with security providers, etc. and be able to offer some suggestions.

Thanks for any help.

Hi all -

I am trying to gather some requirements for a project just starting up, and part of the request from marketing is to be able to track and maintain email bouncebacks via a custom admin screen. Currently we simply submit a simple email message to the sendmail server using JavaMail. To satisfy the request, we would need to be able to:

Treat bounced-back email messages differently based on the failure reason (mailbox full vs. invaid email address).

Identify different types of email messages we send in a more reliable manner than depending on the subject line (via some sort of custom ID we assign when sending).

Possibly configure the service to resend the email based on why it failed to deliver.

Manually resend the original (or send to an alternate address), requiring that the original email content be retained.

Somehow tie the email to a specific user in the system via some custom header info or the like, since an email address in our system need not be unique.

Anyone implemented one or more of these features using JavaMail and/or Apache James? Or perhaps integrated with a major third-party product which provides similar functionality and also allows for custom integration?

Thanks for any help.

Disregard. Don't know what I was thinking, but the startManaged script calls /common/bin/commEnv.sh, not the setEnv script. Still, there is a declaration of JAVA_HOME there too.

Hi all

I was wondering why by defualt both the setEnv.sh and startManagedWebLogic.sh scripts set a value for JAVA_HOME when the startManagedWebLogic script sources the setEnv script. I can see having the option to override the value in the startManagedWebLogic script, but why have it there by default? I am working on a migration to SP4, and (due to the new JDK) need to change more files than I would have otherwise. Can't I comment out the JAVA_HOME set in startManaged, and let the declaration in setEnv be my default for all scripts referencing it?

Thanks for any input.

For what it's worth, I tried adjusting the memory settings:

-XX:MaxPermSize=256m -Xmx512m

The defualt for MaxPerm appears to have been 128. As it happens, making it 256 effectively doubled the number of times I could redeploy before the OOM was seen. I do not rule out our application as a culprit in this, but with the two issues listed in the SP4 and SP5 release notes about this very thing, I am looking to WL first.

Thanks for the response. I am wondering though if this is more of a work around than an actual solution. Seems to be that if WLS is taking more and more memory when doing redeployments, by increasing the memory settings we are only buying ouselves more time between "OutOfMemory" exceptions. Our goal is to remain as highly available as possible, and our process involves doing a hot deployment to an inactive cluster while running, and then switching that cluster to be the active one. Ideally avoiding a server restart.

I was wondering what the common practice is among those using WLS. Do you always, when deploying to production, restart WL? We have a very short turnaround, deploying to production every week. We have gathered by talking to some that we seem to be more likely to see this issue given the frequency of deployments and the fact that we had not been restarting WL on every deployment (we are now restarting each time due to this issue).

I have looked for some advice on deployment best/common practices, but have found none so far. A quick reply from a few folks on how you handle production deployments would be appreciated.

Thanks.

Hi all,

I was wondering if anyone else has run into the issue of repeated redeployments via the WebLogic console causing an "Out of memory" error in the server, requiring a restart.

We have an application (deployed in exploded directory form) comprised of five web applications and six or so EJB Jars. When choosing "redeploy" through the console to redeploy to a cluster, it will fail on about the tenth try.

According to the SP4 release notes, this should be fixed, but a similar issue related to web applications (CR205146 CR209670) is claimed to be fixed in SP5 (not yet released). I am wondering if there are others who have seen this same issue and maybe have developed a workaround.

SP4 Notes

SP5 Notes

Anyone have an idea when SP5 should be avialable?

Thanks

Hi all,

We had our application running just fine under 8.1, and tried to upgrade to 8.1 SP4 (we have since learned that the issue is present in SP2+). The issue seems to be around the JNDI configuration. We have an object which creates an InitialContext from properties stored in a file. When those properties contain "java.naming.security.principal" and "java.naming.security.credentials", the code which creates and binds to that InitialContext works fine, but (after that) the application will fail to deploy and the server will actually fail to start:

weblogic.management.NoAccessRuntimeException: Access not allowed for subject: principals=[], on ResourceType: Application Action: write, Target: Deployed

The odd thing is that this object is impemented as a Singleton, and when we remove the check for NULL and perform our initialization (creating the Context) each time the reference is requested, it works fine.

Anybody got any ideas?

Thanks in advance.

The ugly trace:

weblogic.management.NoAccessRuntimeException: Access not allowed for subject: principals=[], on ResourceType: Application Action: write, Target: Deployed
at weblogic.management.internal.SecurityHelper$IsAccessAllowedPrivilegeAction.wlsRun(SecurityHelper.java:623)
at weblogic.management.internal.SecurityHelper$IsAccessAllowedPrivilegeAction.run(SecurityHelper.java:510)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.management.internal.SecurityHelper.isAccessAllowed(SecurityHelper.java:398)
at weblogic.management.internal.RemoteMBeanServerImpl.private_setAttribute(RemoteMBeanServerImpl.java:430)
at weblogic.management.internal.RemoteMBeanServerImpl.setAttribute(RemoteMBeanServerImpl.java:387)
at weblogic.management.internal.MBeanProxy.setAttribute(MBeanProxy.java:741)
at weblogic.management.internal.MBeanProxy.invokeForCachingStub(MBeanProxy.java:475)
at weblogic.management.configuration.ApplicationMBean_Stub.setDeployed(ApplicationMBean_Stub.java:408)
at weblogic.management.mbeans.custom.ApplicationManager.setState(ApplicationManager.java:593)
at weblogic.management.mbeans.custom.ApplicationManager.startConfigManager(ApplicationManager.java:740)
at weblogic.management.mbeans.custom.ApplicationManager.start(ApplicationManager.java:501)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:754)
at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:733)
at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:509)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1560)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1528)
at weblogic.management.internal.RemoteMBeanServerImpl.private_invoke(RemoteMBeanServerImpl.java:988)
at weblogic.management.internal.RemoteMBeanServerImpl.invoke(RemoteMBeanServerImpl.java:946)
at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:954)
at weblogic.management.internal.MBeanProxy.invokeForCachingStub(MBeanProxy.java:481)
at weblogic.management.configuration.ApplicationManagerMBean_Stub.start(ApplicationManagerMBean_Stub.java:677)
at weblogic.management.Admin.startApplicationManager(Admin.java:2821)
at weblogic.management.AdminServerAdmin.startApplicationManager(AdminServerAdmin.java:624)
at weblogic.management.Admin.finish(Admin.java:2299)
at weblogic.management.AdminServerAdmin.finish(AdminServerAdmin.java:458)
at weblogic.t3.srvr.T3Srvr.resume(T3Srvr.java:971)
at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:361)
at weblogic.Server.main(Server.java:32)

[ June 02, 2005: Message edited by: Ted Bell ]

I used Poseidon for my project, and had no trouble (though it has been over a year). Silly question - what are you using to view the images you generate from Poseidon? Is it possible they are being shrunk to fit your display by the app?

This speaks to an article I read a couple months back in USA Today. The premise was that these types of measures meant to protect children from hurt feelings of criticism end up in the long run hurting them. They grow up and enter the work force where they will often face criticism of their work, and they have a hard time deealing with it. They are not showered with praise at every turn as they were as children and have trouble coping.

Same is true with contests where educators have stopped declaring winners (I even heard some spelling bees being cancelled) in an effort to spare the non-winners disappointment. What happens when these kids grow up and have to really compete for jobs, and they don't win?

Sometimes life is disappointing, and educators are doing kids a disservice trying to protect them from this rather than help them deal with it.

Update:

I download the file from two machines with two different results. On my Windows desktop, the file looks fine in notepad and Excel. When I move the servlet to a Solaris box, it renders fine in notepad, but the euro symbol is not displayed correctly in excel. The difference (or the only difference I have found so far) seems to be related to the "file.encoding" system property. On Windows it is "cp1252" and on Solaris it's coming as "ISO8859-15", which I think was changed from the default (whatever it was) by a sysadmin.

Hi all,

I have a servlet to turn out some values in a CSV file. Everything works fine except that in some cases the file can have special German characters and the Euro symbol. When I download the file and open in Notepad, everything looks fine (using UTF-8 encoding). When opening in Excel however, it does not. I have read in other forums that Excel does not like UTF-8, but I can't find a way to encode it that Excel does like.

The content being output is represented in the code as a String (parsed from a Velocity template). I saw something somewhere that Strings and byte arrays behave differently.

There has to be a way to handle this. Is there some conversion on the content I should do prior to outputting?

Any help appreciated.

Apologies if I am missing something here, but any information (even an educated guess) would be appreciated.

That would make sense if I were not setting the character encoding, but I am:

response.setContentType("application/ms-excel;charset=UTF-8");

In fact a line immediately after this with a call to resposne.getCharacterEncoding() returns "UTF-8".