We are developing a Vaadin application, running it on oc4j 10.1.3.
After implementing basic authentication, the user's session gets invalidated automatically, within the timeout (which is the default).
So, a user opens the Vaadin application and on one point there should be some data set as session attributes for an other servlet. However, at that time, we have an exception saying that the session in already invalidated. It is never called explicitly, maybe oc4j does it?
It was working fine before the authentication has been implemented.
Aug 13, 2012 4:21:27 PM com.vaadin.Application terminalError
SEVERE: Terminal error:
com.vaadin.event.ListenerMethod$MethodException: Invocation of method buttonClick in com.mycompany.myapp$1 failed.
at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:530)
at com.vaadin.event.EventRouter.fireEvent(EventRouter.java:164)
at com.vaadin.ui.AbstractComponent.fireEvent(AbstractComponent.java:1219)
at com.vaadin.ui.Button.fireClick(Button.java:567)
at com.vaadin.ui.Button.changeVariables(Button.java:223)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.changeVariables(AbstractCommunicationManager.java:1460)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.handleVariableBurst(AbstractCommunicationManager.java:1404)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.handleVariables(AbstractCommunicationManager.java:1329)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.doHandleUidlRequest(AbstractCommunicationManager.java:761)
at com.vaadin.terminal.gwt.server.CommunicationManager.handleUidlRequest(CommunicationManager.java:318)
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:501)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:64)
at com.mycompany.myapp.RewriteFilter.doFilter(RewriteFilter.java:44)
at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:644)
at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:391)
at com.evermind.server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:908)
at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:458)
at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:313)
at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:199)
at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260)
at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalStateException: Session was invalidated
at com.evermind.server.http.EvermindHttpSession.setAttribute(EvermindHttpSession.java:158)
at com.evermind.server.http.EvermindHttpSession.setAttribute(EvermindHttpSession.java:137)
at com.mycompany.myapp$1.buttonClick(MyPage.java:105)
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:585)
at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:510)
... 22 more
After implementing a HttpSessionListener, i've found that the session itself is valid. Something must be wrong on the Vaadin side, b/c setting the session as a variable in my Application implementation from a HttpServletRequestListener.onRequestStart method, that session instance is okay.
Related
I am trying to deploy a war file into Wildfly 10.0.0.Final, the deployment fails with the following error :
"{\"WFLYCTL0080: Failed services\" => {\"jboss.deployment.unit.\\\"management-app.war\\\".WeldStartService\" => \"org.jboss.msc.service.StartException in service jboss.deployment.unit.\\\"management-app.war\\\".WeldStartService: Failed to start service
Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getReference() is not available during application initialization
at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerState(BeanManagerProxy.java:242)
at org.jboss.weld.bean.builtin.BeanManagerProxy.getReference(BeanManagerProxy.java:84)
at morpho.mcp.adapter.cdi.AdapterExtension.getAdapterDefinition(AdapterExtension.java:159)
at morpho.mcp.adapter.cdi.AdapterExtension.afterBeanDiscovery(AdapterExtension.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
at org.jboss.weld.injection.MethodInvocationStrategy$SpecialParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:144)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:309)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:287)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:271)
at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:260)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:154)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:148)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:61)
at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:423)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)
at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:95)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
\"}}"
Assuming that the war was working fine for JBoss AS7. What could be the possible root cause for such behavior ?
It seems that a WAR which is not a bean archive is missing the org.jboss.as.weld.WeldStartService dependency. But how can this issue be resolved ?
But how can this issue be resolved ?
Do not use BeanManager.getReference before AfterDeploymentValidation. Refactor your code accordingly. The reason is - getReference might give you incomplete results. At that point, the bootstrap is not yet done and getReference method might fail to retrieve a reference as there might not be one at a given time (although it would be there later on).
As for how to workaround this:
Use Weld non-portable mode although that might have more undesirable effects. You should firstly try to refactor the code before falling back to this configuration.
Good afternoon,
When I attempt to use the SMTP Appender, I get an odd error in the console. The error appears to occur when the XML file is loaded, as it isn't logged via any output stream except stdout. The contents of the appender are as follows (and I have confirmed that the error is in this block of XML). I've removed our server information.
<SMTP name="Mailer">
<Subject>[ERROR] (software name) on ${hostName} has thrown a fatal error</Subject>
<To>(a valid email in the form of a#a.com)</To>
<From>(a valid email in the form of a#a.com)</From>
<SMTPHost>(The Internal IP address of a server in the form of 192.168.0.1)</SMTPHost>
<SMTPPort>587</SMTPPort>
<BufferSize>512</BufferSize>
</SMTP>
Whether or not it is referenced in a logger, I receive the following error immediately upon running the program and running getLogger from the log manager. I've removed a couple of the file names and replaced them with a rough description of what the file is doing at that point.
2015-05-19 19:08:18,812 ERROR Unable to invoke factory method in class class org.apache.logging.log4j.core.appender.SmtpAppender for element SMTP. java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:137)
at org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:766)
at org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:706)
at org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:698)
at org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:358)
at org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:161)
at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:361)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:426)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:442)
at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:138)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:147)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:41)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:175)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:426)
at (Our Log Interface Class, which essentially just returns the log passed by the Apache log manager)
at (The global variable definition file, the first method to use getLogger)
at (The main method for our software, where the globals are loaded)
Caused by: java.lang.NoSuchMethodError: javax.mail.Session.setProtocolForAddress(Ljava/lang/String;Ljava/lang/String;)V
at org.apache.logging.log4j.core.net.SmtpManager$SMTPManagerFactory.createManager(SmtpManager.java:325)
at org.apache.logging.log4j.core.net.SmtpManager$SMTPManagerFactory.createManager(SmtpManager.java:299)
at org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:71)
at org.apache.logging.log4j.core.net.SmtpManager.getSMTPManager(SmtpManager.java:124)
at org.apache.logging.log4j.core.appender.SmtpAppender.createAppender(SmtpAppender.java:142)
... 21 more
2015-05-19 19:08:18,814 ERROR Null object returned for SMTP in Appenders.
2015-05-19 19:08:18,819 ERROR Unable to locate appender Mailer for logger fatalerror
The details of the configuration are correct (I know it's a valid IP, etc) - they worked in log4j 1. The error log tells me virtually nothing about the error, so I am hoping someone has heard of this before. Thanks everyone!
This is the important line from your stacktrace:
Caused by: java.lang.NoSuchMethodError: javax.mail.Session.setProtocolForAddress(Ljava/lang/String;Ljava/lang/String;)V
The setProtocolForAddress method has been part of JavaMail since version 1.4, so this suggests to me that you are using an old version of that JAR. If you are, try upgrading to a later version.
Note that log4j2 has many lookups, not just system properties. So you need to convert ${hostName} to ${sys:hostName}, and if you are using a lookup for the IP address, this may be the cause of the issue. (Try hardcoding all lookup values to exclude this possibility.)
I do get the following exception in Liferay 6.1.20 EE when I try to get a JournalArticleDisplay with a template. The template exists, the JournalArticle exists - everything is fine ;) And the same code works in 6.1.30 EE ;)
But as soon as I call this method in 6.1.20 EE, it breaks because companyId shall not be 0 :
Caused by: com.liferay.portal.kernel.templateparser.TransformException: Unhandled exception
at com.liferay.portal.kernel.templateparser.BaseTemplateParser.transform(BaseTemplateParser.java:135)
at com.liferay.portal.kernel.templateparser.BaseTransformer.transform(BaseTransformer.java:163)
at com.liferay.portlet.journal.util.JournalUtil.transform(JournalUtil.java:1036)
at com.liferay.portlet.journal.service.impl.JournalArticleLocalServiceImpl.getArticleDisplay(JournalArticleLocalServiceImpl.java:1090)
... 87 more
Caused by: com.liferay.portal.NoSuchCompanyException: No Company exists with the primary key 0
at com.liferay.portal.service.persistence.CompanyPersistenceImpl.findByPrimaryKey(CompanyPersistenceImpl.java:486)
at com.liferay.portal.service.base.CompanyLocalServiceBaseImpl.getCompany(CompanyLocalServiceBaseImpl.java:385)
at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:122)
at com.liferay.portal.spring.transaction.TransactionInterceptor.invoke(TransactionInterceptor.java:71)
at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:118)
at com.liferay.portal.spring.aop.ServiceBeanAopProxy.invoke(ServiceBeanAopProxy.java:211)
at com.sun.proxy.$Proxy113.getCompany(Unknown Source)
at com.liferay.portal.service.CompanyLocalServiceUtil.getCompany(CompanyLocalServiceUtil.java:181)
at com.liferay.portal.kernel.templateparser.BaseTemplateParser.getCompany(BaseTemplateParser.java:150)
at com.liferay.portal.kernel.templateparser.BaseTemplateParser.populateTemplateContext(BaseTemplateParser.java:244)
at com.liferay.portlet.journal.util.VelocityTemplateParser.populateTemplateContext(VelocityTemplateParser.java:178)
at com.liferay.portal.kernel.templateparser.BaseTemplateParser.transform(BaseTemplateParser.java:120)
... 90 more
I am sorry if I caused trouble.
This seems to be a Liferay Bug : https://issues.liferay.com/browse/LPS-25275
We will upgrade our server ...
I'm running the following tutorial:
http://download.oracle.com/javase/6/docs/technotes/guides/security/jgss/tutorials/BasicClientServer.html
I'm getting the following prompts:
Connected to server localhost/127.0.0.1
Kerberos username [login]: {I enter my username here}
Kerberos password for login: {I enter my password here}
I get the following error:
Can you ascertain the root cause of this?
Exception in thread "main" GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))
at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:333)
at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:128)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:106)
at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:172)
at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:209)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:195)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:162)
at demo.SampleClient.main(SampleClient.java:145)
Caused by: javax.security.auth.login.LoginException: Message stream modified (41)
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:696)
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:542)
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:597)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$5.run(LoginContext.java:706)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:703)
at javax.security.auth.login.LoginContext.login(LoginContext.java:575)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:246)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:136)
at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:328)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:325)
... 7 more
Caused by: KrbException: Message stream modified (41)
at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:53)
at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:96)
at sun.security.krb5.KrbAsReq.getReply(KrbAsReq.java:449)
at sun.security.krb5.Credentials.sendASRequest(Credentials.java:410)
at sun.security.krb5.Credentials.acquireTGT(Credentials.java:378)
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:662)
... 23 more
I got exceptions “Message stream modified (41)”, when the Kerberos realm didn’t match. The realm (in system property java.security.krb5.realm) has to match exactly, including upper/lower case.
I'm wondering if this is a possibility (ie even if registry key is set, locked out for local administrators):
http://cr.openjdk.java.net/~weijun/special/krb5winguide-2/raw_files/new/kwin
Known Issues
If an AD account is also added into local administrator group on the
client PC, Microsoft restricts such client from getting the session key
for tickets (even if you set the allowtgtsessionkey registry key to 1).
The workaround is: Just forget you're a logged in user, call kinit.exe.
Do not depends on LSA credential cache.
I cannot confirm that issue. I do have admin rights on my machine and still are able to obtain the session key from the LSA. You should enable full debug ouput on JGSS and the Krb5LoginModule. Share your krb5.ini and login.conf too. I hope your are aware that the above example cannot work because your client cannot obtain a ticket for a local host. It has to be a FQDN with an appropriate SPN set in the Active Directory.
I am basically walking the LDAP tree in Active Directory.
At each level I query for "(objectClass=*)". When I do this on the root eg "dc=example,dc=com" I get the exception below. This works fine on our other LDAP instances. For some reason only on our Active Directory server I get this exception. I also get the same exception when using JXplorer on our Active Directory server.
From reading around online I found people saying you should turn on following, not sure what that means... So on my controls object (javax.naming.directory.SearchControls) that I pass with the query I call searchControls.setDerefLinkFlag(true). I also have tried setting it to false with the same result. Any a suggestions on what else could cause this? Maybe how I could fix it?
Note: In this post I changed the baseDn from dc=<my company domain> to example for my companies privacy.
javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=example,dc=com'
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2820)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2794)
at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1826)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1749)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:368)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:338)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:321)
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:248)
at com.motio.pi.gui.panels.useraccess.ldap.LDAPConnector.query(LDAPConnector.java:262)
at com.motio.pi.gui.selector.directory.CognosDirectoryBrowserController.expandCognosTreeNode(CognosDirectoryBrowserController.java:99)
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:597)
at com.motio.pi.utils.PIThreadDelegate$1.run(PIThreadDelegate.java:54)
at java.lang.Thread.run(Thread.java:662)
So when I was creating my naming context with the method:
javax.naming.ldap.InitialLdapContext.InitialLdapContext(
Hashtable<?, ?> environment, Control[] connCtls)
In the argument environment there is a property with the name Context.REFERRAL and its value should be set to: follow. This was the setting that I needed.
If you get an exception while referral usage in follow (for example: connection timed out) you can use referral ignore but you dont want to get partial exception you can use 3268 port number instead of 389 this port is using global catalog for ldap. You can find info from following link;
https://technet.microsoft.com/en-us/library/how-global-catalog-servers-work(v=ws.10).aspx