[Tomcat, HTTPD, Servlets & JSP] - Tomcat not recognizing the Authorization header correctly
by reinerka
I've got a very strange problem on JBoss 4.0.5GA.
Sometimes the Authorization header is not recognized from a client that connects to a Servlet causing the message not to go through.
The input message I receive is:
| POST
| /test/test HTTP/1.1
| Content-Type: text/xml; charset=ISO-8859-1
| Host: 24.8.57.55
| User-Agent: XYZ
| SOAPAction:
| Transfer-Encoding: chunked
| Authorization: Digest username="user", realm="realm", algorithm="MD5", nonce="c438968cdef37b7e73428a99feb5e6d9", uri="/test/test", qop=auth, nc=00000001, cnonce="0a1b6aa33254ff169a1b947a6bdbd4c9", response="b7807de2c326469f35dcc0ed9fcdd2f6", opaque="624bdd3901492315b8642e3d330d6505"
|
|
| 594
|
|
When running the server the following is shown in the log file:
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] REQUEST URI =/test/test
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] authType=null
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] characterEncoding=ISO-8859-1
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] contentLength=-1
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] contentType=text/xml; charset=ISO-8859-1
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] contextPath=/dps
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] header=content-type=text/xml; charset=ISO-8859-1
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] header=host=192.168.0.43
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] header=user-agent=XYZ
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] header=soapaction=
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] header=transfer-encoding=chunked
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] locale=en_US
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] method=POST
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] pathInfo=null
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] protocol=HTTP/1.1
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] queryString=null
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] remoteAddr=192.168.0.44
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] remoteHost=192.168.0.44
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] remoteUser=null
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] requestedSessionId=null
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] scheme=http
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] serverName=192.168.0.43
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] serverPort=80
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] servletPath=/test
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] isSecure=false
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] ---------------------------------------------------------------
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] ---------------------------------------------------------------
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] authType=null
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] contentLength=-1
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] contentType=text/html;charset=utf-8
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] header=WWW-Authenticate=Digest realm="realm", qop="auth", nonce="587a0b0f9dc6a03a8068c3b0ca45b09a", opaque="040b835c13a747365e34f239a0f69d02"
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] message=null
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] remoteUser=null
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] status=401
| INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]] ===============================================================
|
The Authorization header is completely lost in Tomcat/Catalina.
Anybody having an idea on what is happening here?
Thanks,
Reiner
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4035489#4035489
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4035489
19 years
[JBoss Seam] - Re: Multiple Domain Quesiton
by spambob
Thank you very much for your response Peter!
In fact http://jira.jboss.com/jira/browse/JBSEAM-769 seems to be exactly what I want but unfortunately I'm not this deep into Seams inner mechanics (in fact I don't have the slightest bit of an idea how this is implemented internally) - and I'm drowning in work (who's not).
So I probably won't have time (or the knowledge) to fix it myself but instead I hope for some brighter minds than myself to implement this ;).
Regardless of the above I'm not really sure what would be the best way to implement this because the reason for this request is only to "obfuscate" / redirect upon an (Authorization)Exception upon a view request (so the AuthorizationExceptions created while handling the already allowed view request are handled like they are now - like they would be handled without this addition).
What do you think about this (especially about overwriting the exception mapping only for page requests / views and not the internal execution) - and how much work would this change require (just a raw guess)?
PS: I sign your request to be able to overwrite exception mapping but regarding this subject it might be more than needed / wanted.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4035484#4035484
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4035484
19 years
[JBoss Seam] - Changes not persisted using EntityHome
by gzoller
Hello,
This may sound like a Hibernate issue (it might be), but I'm leaning toward the opinion that its more related to how I'm using Seam/contexts.
I'm using an entityManager object to handle a DataModel as shown in the Seam tutorial Chapter 1. I have a simple display screen with a delete link next to each line item, which calls #{timecardManager.delete}
Stripped a bit the manager looks like this:
| @Stateful
| @Scope(ScopeType.SESSION)
| @Name("timecardManager")
| public class TimecardManagerBean implements TimecardManager
| {
| @DataModel
| private List<Timecard> tcList;
|
| @DataModelSelection
| @Out(required=false)
| private Timecard tc;
|
| @In
| private ProjectHome projectHome;
|
| @Factory("tcList")
| public void findTimecards()
| {
| tc = null;
| tcList = projectHome.getInstance().getTimecards();
| }
|
| public void delete() {
| projectHome.getInstance().getTimecards().remove(tc);
| tc = null;
| }
|
| @Remove @Destroy
| public void destroy() {}
| }
|
A snip of the display code that calls delete looks like this:
| <h:dataTable id="timecardListResults" width="100%" cellspacing="0" cellpadding="0"
| value="#{tcList}" var="tc"
| rendered="#{tcList.rowCount>0}">
| <h:column>
| <h:commandLink
| value="Delete"
| action="#{timecardManager.delete}"
| rendered="#{s:hasRole('ADMIN')}"/>
| </h:column>
| </h:dataTable>
|
My problem is this... When the users clicks "Delete" #{timecardManager.delete} is successfully called and the doomed item is removed from the in-memory list when the screen is re-rendered. But... no deletions actually make it to the database (Timecard table)! The parent table's (Project) version number is updated in the database however.
The relationship annotation in Project.java for the timecard property looks like this:
| @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy = "project")
|
Why wouldn't my deletion be persisted?
I have another child of Project, Capex. It also has line-item links but they take the user to an intermediate edit screen (within a conversation), so if a delete button is pressed on this screen nearly identical code in capexManager is called and this time deletions are persisted as desired/expected.
Thinking that maybe persistence works if you delete from the child EntityHome first, I tried modifying my timecardManager.delete to look like this:
|
| @In(create=true)
| private TimecardHome timecardHome;
|
| public void delete() {
| // projectHome.getInstance().getTimecard().remove(tc);
|
| timecardHome.setId(new Long(tc.getTimecardId()));
| timecardHome.find();
| timecardHome.wire();
| timecardHome.remove();
| tc = null;
| }
|
|
but this only gave me the following exception (dies in EntityHome.remove() on a flush() call). I've checked, and after the find/wire but before the remove() timecardHome seems healthy: non-null instance, managed, wired.
| (snip)
| Caused by: javax.persistence.EntityNotFoundException: deleted entity passed to persist: [com.paragon.spurs.model.Timecard#<null>]
| at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:625)
| at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:299)
| at org.jboss.seam.persistence.EntityManagerProxy.flush(EntityManagerProxy.java:83)
| at org.jboss.seam.framework.EntityHome.remove(EntityHome.java:60)
| 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.jboss.seam.util.Reflections.invoke(Reflections.java:20)
| at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:57)
| at org.jboss.seam.interceptors.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:47)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
| at org.jboss.seam.interceptors.ManagedEntityIdentityInterceptor.aroundInvoke(ManagedEntityIdentityInterceptor.java:37)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
| at org.jboss.seam.interceptors.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:34)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
| at org.jboss.seam.interceptors.TransactionInterceptor$1.work(TransactionInterceptor.java:32)
| at org.jboss.seam.util.Work.workInTransaction(Work.java:37)
| at org.jboss.seam.interceptors.TransactionInterceptor.aroundInvoke(TransactionInterceptor.java:27)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
| at org.jboss.seam.interceptors.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:27)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
| at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:103)
| at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:151)
| at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:87)
| at com.paragon.spurs.model.TimecardHome_$$_javassist_14.remove(TimecardHome_$$_javassist_14.java)
| at com.paragon.spurs.TimecardManagerBean.delete(TimecardManagerBean.java:89)
| 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.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
| at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
| at org.jboss.seam.intercept.EJBInvocationContext.proceed(EJBInvocationContext.java:37)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:57)
| at org.jboss.seam.interceptors.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:47)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
| at org.jboss.seam.interceptors.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:27)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
| at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:103)
| at org.jboss.seam.intercept.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:53)
| at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:118)
| at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
| ... 84 more
|
Thanks in advance,
Greg
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4035470#4035470
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4035470
19 years