You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Fe...@t-systems.com on 2009/01/14 11:52:55 UTC
[Bug? Trinidad] javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher
Hi,
I've got a serious problem with my frontends. Extremely sudden the
exception below is thrown. Restarting the Container does not work.
Redeploying doesn't help immediately. I have to close all browser
windows an redeploy the application many times until it works. The error
is not reproducible and there is no root cause from one of our own
classes. A simple frontend page (small login) which works fine hundreds
of time suddenly fails and the whole application is down after this
exception.
Trinidad Version: 1.2.10
MyFaces 1.2.6
Is this problem / are any workarounds known?
Shall I open a ticket in the JIRA?
Regards
Felix
==> logs/localhost.2009-01-14.log <==
Jan 14, 2009 5:42:54 AM org.apache.catalina.core.StandardWrapperValve
invoke
SEVERE: Servlet.service() for servlet Faces Servlet threw exception
javax.crypto.IllegalBlockSizeException: Input length must be multiple of
8 when decrypting with padded cipher
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..)
at javax.crypto.Cipher.doFinal(DashoA13*..)
at
org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java
:369)
at
org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java
:411)
at
org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:2
91)
at
org.apache.myfaces.shared_impl.util.StateUtils.reconstruct(StateUtils.ja
va:240)
at
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getSavedState
(HtmlResponseStateManager.java:187)
at
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getState(Html
ResponseStateManager.java:139)
at
org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspSt
ateManagerImpl.java:346)
at
org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspVie
wHandlerImpl.java:515)
at
org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExec
utor.java:85)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.ja
va:103)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76
)
at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:151)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:206)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoF
ilter(TrinidadFilterImpl.java:238)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterI
mpl(TrinidadFilterImpl.java:195)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(T
rinidadFilterImpl.java:138)
at
org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilte
r.java:92)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:206)
at
com.satellic.etcng.cas.updatemanagement.util.MyFacesBugFixFilter.doFilte
r(MyFacesBugFixFilter.java:54)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
86)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84
5)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Re: [Bug? Trinidad] javax.crypto.IllegalBlockSizeException: Input
length must be multiple of 8 when decrypting with padded cipher
Posted by Matthias Wessendorf <ma...@apache.org>.
Felix,
do you mind to file a JIRA ticket against myfaces (the core) ?
Thx,
M
On Wed, Jan 14, 2009 at 7:24 AM, Cagatay Civici
<ca...@gmail.com> wrote:
> I've seen this error even in myfaces 1.2.2.
>
> There's an annoying problem with client side viewstate encryption.
>
> On Wed, Jan 14, 2009 at 2:53 PM, Matthias Wessendorf <ma...@apache.org>
> wrote:
>>
>> Hi know that there is some param on myfaces core for this.
>> So, does that work with MyFaces 1.2.6 standalone ?
>> Did this used to before upgrading to Trinidad 1.2.10 ?
>>
>> -M
>>
>> On Wed, Jan 14, 2009 at 2:52 AM, <Fe...@t-systems.com> wrote:
>> > Hi,
>> >
>> >
>> >
>> > I've got a serious problem with my frontends. Extremely sudden the
>> > exception
>> > below is thrown. Restarting the Container does not work. Redeploying
>> > doesn't
>> > help immediately. I have to close all browser windows an redeploy the
>> > application many times until it works. The error is not reproducible and
>> > there is no root cause from one of our own classes. A simple frontend
>> > page
>> > (small login) which works fine hundreds of time suddenly fails and the
>> > whole
>> > application is down after this exception.
>> >
>> >
>> >
>> > Trinidad Version: 1.2.10
>> >
>> > MyFaces 1.2.6
>> >
>> >
>> >
>> > Is this problem / are any workarounds known?
>> >
>> >
>> >
>> > Shall I open a ticket in the JIRA?
>> >
>> >
>> >
>> > Regards
>> >
>> >
>> >
>> > Felix
>> >
>> >
>> >
>> > ==> logs/localhost.2009-01-14.log <==
>> >
>> > Jan 14, 2009 5:42:54 AM org.apache.catalina.core.StandardWrapperValve
>> > invoke
>> >
>> > SEVERE: Servlet.service() for servlet Faces Servlet threw exception
>> >
>> > javax.crypto.IllegalBlockSizeException: Input length must be multiple of
>> > 8
>> > when decrypting with padded cipher
>> >
>> > at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
>> >
>> > at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
>> >
>> > at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..)
>> >
>> > at javax.crypto.Cipher.doFinal(DashoA13*..)
>> >
>> > at
>> >
>> > org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:369)
>> >
>> > at
>> >
>> > org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:411)
>> >
>> > at
>> >
>> > org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:291)
>> >
>> > at
>> >
>> > org.apache.myfaces.shared_impl.util.StateUtils.reconstruct(StateUtils.java:240)
>> >
>> > at
>> >
>> > org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getSavedState(HtmlResponseStateManager.java:187)
>> >
>> > at
>> >
>> > org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getState(HtmlResponseStateManager.java:139)
>> >
>> > at
>> >
>> > org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:346)
>> >
>> > at
>> >
>> > org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:515)
>> >
>> > at
>> >
>> > org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:85)
>> >
>> > at
>> >
>> > org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
>> >
>> > at
>> >
>> > org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
>> >
>> > at
>> > javax.faces.webapp.FacesServlet.service(FacesServlet.java:151)
>> >
>> > at
>> >
>> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>> >
>> > at
>> >
>> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>> >
>> > at
>> >
>> > org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:238)
>> >
>> > at
>> >
>> > org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:195)
>> >
>> > at
>> >
>> > org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:138)
>> >
>> > at
>> >
>> > org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
>> >
>> > at
>> >
>> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>> >
>> > at
>> >
>> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>> >
>> > at
>> >
>> > com.satellic.etcng.cas.updatemanagement.util.MyFacesBugFixFilter.doFilter(MyFacesBugFixFilter.java:54)
>> >
>> > at
>> >
>> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>> >
>> > at
>> >
>> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>> >
>> > at
>> >
>> > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>> >
>> > at
>> >
>> > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>> >
>> > at
>> >
>> > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>> >
>> > at
>> >
>> > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>> >
>> > at
>> >
>> > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>> >
>> > at
>> >
>> > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
>> >
>> > at
>> >
>> > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
>> >
>> > at
>> >
>> > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
>> >
>> > at
>> > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>> >
>> > at java.lang.Thread.run(Thread.java:619)
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [myfaces-core] javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher
Posted by Mike Kienenberger <mk...@gmail.com>.
One possible cause of the issue could be that your submitted page
values are exceeding some limit, and you're not getting the entire
form submitted. Some setups have a 4K limit -- I've hit this on an
Apache web server with a proxy server going to an Oracle app server.
Another possibility is that your generated html has some other output
in the middle of your encrypted state data. I've seen things like
exceptions written out in the middle of the data at times.
And lastly it's possible that sometimes the generated html isn't
completely written out. I've had this happen in certain situations
with Oracle app servers, where the page generated wasn't flushed
completely to the client, leaving a partial encrypted form value.
So the next time it happens, save a copy of the original html that
you're submitting from, and try to capture a copy of the form data you
are submitting.
Make sure that the generated html is intact and all there. And check
to see how much data you're posting back to the server.
On Wed, Jan 14, 2009 at 11:23 AM, <Fe...@t-systems.com> wrote:
>
> Hi Simon,
>
>> I think any of the following (in order of preference) should solve
> this:
>>
>> (1) in web.xml, define init-parameter "org.apache.myfaces.SECRET" to
> be
>> some reasonably long string. The server will then use the same
>> encryption secret after restart (instead of generating a key itself),
>> and so will be able to decrypt "old" sessions.
> Tried it, didn't help.
>>
>> (2) in web.xml, define init-parameter
>> "org.apache.myfaces.USE_ENCRYPTION" to be "false", in order to
> disable
>> client-side state encryption. Of course this potentially opens a
>> security hole in the app.
> Tried it, didn't help.
>>
>> (3) use server-side state saving (only client-side state is encrypted)
> Tried it, didn't help.
>> </quote>
>
>
> Felix
>
RE: [myfaces-core] javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher
Posted by Fe...@t-systems.com.
Hi Simon,
> I think any of the following (in order of preference) should solve
this:
>
> (1) in web.xml, define init-parameter "org.apache.myfaces.SECRET" to
be
> some reasonably long string. The server will then use the same
> encryption secret after restart (instead of generating a key itself),
> and so will be able to decrypt "old" sessions.
Tried it, didn't help.
>
> (2) in web.xml, define init-parameter
> "org.apache.myfaces.USE_ENCRYPTION" to be "false", in order to
disable
> client-side state encryption. Of course this potentially opens a
> security hole in the app.
Tried it, didn't help.
>
> (3) use server-side state saving (only client-side state is encrypted)
Tried it, didn't help.
> </quote>
Felix
Re: [myfaces-core] javax.crypto.IllegalBlockSizeException: Input
length must be multiple of 8 when decrypting with padded cipher
Posted by Simon Kitching <sk...@apache.org>.
I meant issue
https://issues.apache.org/jira/browse/MYFACES-1838
Simon Kitching schrieb:
> I've added a note on the bugzilla issue
> https://issues.apache.org/jira/browse/MYFACES-1786:
>
> <quote>
> I don't believe this is a bug at all. Unless I've misunderstood
> something, it's just missing configuration.
>
> I think any of the following (in order of preference) should solve this:
>
> (1) in web.xml, define init-parameter "org.apache.myfaces.SECRET" to be
> some reasonably long string. The server will then use the same
> encryption secret after restart (instead of generating a key itself),
> and so will be able to decrypt "old" sessions.
>
> (2) in web.xml, define init-parameter
> "org.apache.myfaces.USE_ENCRYPTION" to be "false", in order to disable
> client-side state encryption. Of course this potentially opens a
> security hole in the app.
>
> (3) use server-side state saving (only client-side state is encrypted)
> </quote>
>
> I also added a note on related issue MYFACES-1786:
> <quote>
> state *should* be encrypted by default; no system should default to
> being insecure.
> </quote>
>
> And by the way, this is all related to myfaces-core, and is nothing
> whatsoever to do with Trinidad. I've therefore changed the email subject
> line.
>
> Felix's original complaint is a little different from the jira issue
> referenced. That issue triggers only on servlet-container restart while
> Felix was claiming the problem popped up spontaneously. I suspect that
> there was actually a container restart happening there (eg the container
> is configured to "watch" for changes, and some watched file is being
> touched). Felix, you might want to check your logs : I bet that whenever
> this happens you are also getting a complete webapp restart, ie you've
> got something weird in your environment.
>
> Regards,
> Simon
>
>
>
> Cagatay Civici schrieb:
>> I've seen this error even in myfaces 1.2.2.
>>
>> There's an annoying problem with client side viewstate encryption.
>>
>> On Wed, Jan 14, 2009 at 2:53 PM, Matthias Wessendorf <matzew@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Hi know that there is some param on myfaces core for this.
>> So, does that work with MyFaces 1.2.6 standalone ?
>> Did this used to before upgrading to Trinidad 1.2.10 ?
>>
>> -M
>>
>> On Wed, Jan 14, 2009 at 2:52 AM, <Felix.Becker@t-systems.com
>> <ma...@t-systems.com>> wrote:
>> > Hi,
>> >
>> >
>> >
>> > I've got a serious problem with my frontends. Extremely sudden the
>> exception
>> > below is thrown. Restarting the Container does not work.
>> Redeploying doesn't
>> > help immediately. I have to close all browser windows an redeploy the
>> > application many times until it works. The error is not
>> reproducible and
>> > there is no root cause from one of our own classes. A simple
>> frontend page
>> > (small login) which works fine hundreds of time suddenly fails and
>> the whole
>> > application is down after this exception.
>> >
>> >
>> >
>> > Trinidad Version: 1.2.10
>> >
>> > MyFaces 1.2.6
>> >
>> >
>> >
>> > Is this problem / are any workarounds known?
>> >
>> >
>> >
>> > Shall I open a ticket in the JIRA?
>> >
>> >
>> >
>> > Regards
>> >
>> >
>> >
>> > Felix
>> >
>> >
>> >
>> > ==> logs/localhost.2009-01-14.log <==
>> >
>> > Jan 14, 2009 5:42:54 AM
>> org.apache.catalina.core.StandardWrapperValve invoke
>> >
>> > SEVERE: Servlet.service() for servlet Faces Servlet threw exception
>> >
>> > javax.crypto.IllegalBlockSizeException: Input length must be
>> multiple of 8
>> > when decrypting with padded cipher
>> >
>> > at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
>> >
>> > at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
>> >
>> > at
>> com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..)
>> >
>> > at javax.crypto.Cipher.doFinal(DashoA13*..)
>> >
>> > at
>> >
>> org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:369)
>> >
>> > at
>> >
>> org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:411)
>> >
>> > at
>> >
>> org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:291)
>
>
Re: [myfaces-core] javax.crypto.IllegalBlockSizeException: Input
length must be multiple of 8 when decrypting with padded cipher
Posted by Simon Kitching <sk...@apache.org>.
I've added a note on the bugzilla issue
https://issues.apache.org/jira/browse/MYFACES-1786:
<quote>
I don't believe this is a bug at all. Unless I've misunderstood
something, it's just missing configuration.
I think any of the following (in order of preference) should solve this:
(1) in web.xml, define init-parameter "org.apache.myfaces.SECRET" to be
some reasonably long string. The server will then use the same
encryption secret after restart (instead of generating a key itself),
and so will be able to decrypt "old" sessions.
(2) in web.xml, define init-parameter
"org.apache.myfaces.USE_ENCRYPTION" to be "false", in order to disable
client-side state encryption. Of course this potentially opens a
security hole in the app.
(3) use server-side state saving (only client-side state is encrypted)
</quote>
I also added a note on related issue MYFACES-1786:
<quote>
state *should* be encrypted by default; no system should default to
being insecure.
</quote>
And by the way, this is all related to myfaces-core, and is nothing
whatsoever to do with Trinidad. I've therefore changed the email subject
line.
Felix's original complaint is a little different from the jira issue
referenced. That issue triggers only on servlet-container restart while
Felix was claiming the problem popped up spontaneously. I suspect that
there was actually a container restart happening there (eg the container
is configured to "watch" for changes, and some watched file is being
touched). Felix, you might want to check your logs : I bet that whenever
this happens you are also getting a complete webapp restart, ie you've
got something weird in your environment.
Regards,
Simon
Cagatay Civici schrieb:
> I've seen this error even in myfaces 1.2.2.
>
> There's an annoying problem with client side viewstate encryption.
>
> On Wed, Jan 14, 2009 at 2:53 PM, Matthias Wessendorf <matzew@apache.org
> <ma...@apache.org>> wrote:
>
> Hi know that there is some param on myfaces core for this.
> So, does that work with MyFaces 1.2.6 standalone ?
> Did this used to before upgrading to Trinidad 1.2.10 ?
>
> -M
>
> On Wed, Jan 14, 2009 at 2:52 AM, <Felix.Becker@t-systems.com
> <ma...@t-systems.com>> wrote:
> > Hi,
> >
> >
> >
> > I've got a serious problem with my frontends. Extremely sudden the
> exception
> > below is thrown. Restarting the Container does not work.
> Redeploying doesn't
> > help immediately. I have to close all browser windows an redeploy the
> > application many times until it works. The error is not
> reproducible and
> > there is no root cause from one of our own classes. A simple
> frontend page
> > (small login) which works fine hundreds of time suddenly fails and
> the whole
> > application is down after this exception.
> >
> >
> >
> > Trinidad Version: 1.2.10
> >
> > MyFaces 1.2.6
> >
> >
> >
> > Is this problem / are any workarounds known?
> >
> >
> >
> > Shall I open a ticket in the JIRA?
> >
> >
> >
> > Regards
> >
> >
> >
> > Felix
> >
> >
> >
> > ==> logs/localhost.2009-01-14.log <==
> >
> > Jan 14, 2009 5:42:54 AM
> org.apache.catalina.core.StandardWrapperValve invoke
> >
> > SEVERE: Servlet.service() for servlet Faces Servlet threw exception
> >
> > javax.crypto.IllegalBlockSizeException: Input length must be
> multiple of 8
> > when decrypting with padded cipher
> >
> > at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
> >
> > at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
> >
> > at
> com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..)
> >
> > at javax.crypto.Cipher.doFinal(DashoA13*..)
> >
> > at
> >
> org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:369)
> >
> > at
> >
> org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:411)
> >
> > at
> >
> org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:291)
Re: [Bug? Trinidad] javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher
Posted by Cagatay Civici <ca...@gmail.com>.
I've seen this error even in myfaces 1.2.2.
There's an annoying problem with client side viewstate encryption.
On Wed, Jan 14, 2009 at 2:53 PM, Matthias Wessendorf <ma...@apache.org>wrote:
> Hi know that there is some param on myfaces core for this.
> So, does that work with MyFaces 1.2.6 standalone ?
> Did this used to before upgrading to Trinidad 1.2.10 ?
>
> -M
>
> On Wed, Jan 14, 2009 at 2:52 AM, <Fe...@t-systems.com> wrote:
> > Hi,
> >
> >
> >
> > I've got a serious problem with my frontends. Extremely sudden the
> exception
> > below is thrown. Restarting the Container does not work. Redeploying
> doesn't
> > help immediately. I have to close all browser windows an redeploy the
> > application many times until it works. The error is not reproducible and
> > there is no root cause from one of our own classes. A simple frontend
> page
> > (small login) which works fine hundreds of time suddenly fails and the
> whole
> > application is down after this exception.
> >
> >
> >
> > Trinidad Version: 1.2.10
> >
> > MyFaces 1.2.6
> >
> >
> >
> > Is this problem / are any workarounds known?
> >
> >
> >
> > Shall I open a ticket in the JIRA?
> >
> >
> >
> > Regards
> >
> >
> >
> > Felix
> >
> >
> >
> > ==> logs/localhost.2009-01-14.log <==
> >
> > Jan 14, 2009 5:42:54 AM org.apache.catalina.core.StandardWrapperValve
> invoke
> >
> > SEVERE: Servlet.service() for servlet Faces Servlet threw exception
> >
> > javax.crypto.IllegalBlockSizeException: Input length must be multiple of
> 8
> > when decrypting with padded cipher
> >
> > at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
> >
> > at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
> >
> > at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..)
> >
> > at javax.crypto.Cipher.doFinal(DashoA13*..)
> >
> > at
> >
> org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:369)
> >
> > at
> >
> org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:411)
> >
> > at
> >
> org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:291)
> >
> > at
> >
> org.apache.myfaces.shared_impl.util.StateUtils.reconstruct(StateUtils.java:240)
> >
> > at
> >
> org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getSavedState(HtmlResponseStateManager.java:187)
> >
> > at
> >
> org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getState(HtmlResponseStateManager.java:139)
> >
> > at
> >
> org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:346)
> >
> > at
> >
> org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:515)
> >
> > at
> >
> org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:85)
> >
> > at
> >
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> >
> > at
> > org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> >
> > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:151)
> >
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> >
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> >
> > at
> >
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:238)
> >
> > at
> >
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:195)
> >
> > at
> >
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:138)
> >
> > at
> >
> org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
> >
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> >
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> >
> > at
> >
> com.satellic.etcng.cas.updatemanagement.util.MyFacesBugFixFilter.doFilter(MyFacesBugFixFilter.java:54)
> >
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> >
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> >
> > at
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> >
> > at
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> >
> > at
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> >
> > at
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> >
> > at
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> >
> > at
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
> >
> > at
> >
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
> >
> > at
> >
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> >
> > at
> > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> >
> > at java.lang.Thread.run(Thread.java:619)
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
Re: [Bug? Trinidad] javax.crypto.IllegalBlockSizeException: Input
length must be multiple of 8 when decrypting with padded cipher
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi know that there is some param on myfaces core for this.
So, does that work with MyFaces 1.2.6 standalone ?
Did this used to before upgrading to Trinidad 1.2.10 ?
-M
On Wed, Jan 14, 2009 at 2:52 AM, <Fe...@t-systems.com> wrote:
> Hi,
>
>
>
> I've got a serious problem with my frontends. Extremely sudden the exception
> below is thrown. Restarting the Container does not work. Redeploying doesn't
> help immediately. I have to close all browser windows an redeploy the
> application many times until it works. The error is not reproducible and
> there is no root cause from one of our own classes. A simple frontend page
> (small login) which works fine hundreds of time suddenly fails and the whole
> application is down after this exception.
>
>
>
> Trinidad Version: 1.2.10
>
> MyFaces 1.2.6
>
>
>
> Is this problem / are any workarounds known?
>
>
>
> Shall I open a ticket in the JIRA?
>
>
>
> Regards
>
>
>
> Felix
>
>
>
> ==> logs/localhost.2009-01-14.log <==
>
> Jan 14, 2009 5:42:54 AM org.apache.catalina.core.StandardWrapperValve invoke
>
> SEVERE: Servlet.service() for servlet Faces Servlet threw exception
>
> javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8
> when decrypting with padded cipher
>
> at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
>
> at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
>
> at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..)
>
> at javax.crypto.Cipher.doFinal(DashoA13*..)
>
> at
> org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:369)
>
> at
> org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:411)
>
> at
> org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:291)
>
> at
> org.apache.myfaces.shared_impl.util.StateUtils.reconstruct(StateUtils.java:240)
>
> at
> org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getSavedState(HtmlResponseStateManager.java:187)
>
> at
> org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getState(HtmlResponseStateManager.java:139)
>
> at
> org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:346)
>
> at
> org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:515)
>
> at
> org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:85)
>
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
>
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
>
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:151)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>
> at
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:238)
>
> at
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:195)
>
> at
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:138)
>
> at
> org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>
> at
> com.satellic.etcng.cas.updatemanagement.util.MyFacesBugFixFilter.doFilter(MyFacesBugFixFilter.java:54)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
>
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
>
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
>
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>
> at java.lang.Thread.run(Thread.java:619)
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf