[Fedora-commons-users] Ingest problem with 3.2 REST API

[Willy Mene]

I'm playing with our Fedora 3.2 instance and the REST API. I'm using
the Firefox Poster add-on to do an http POST of some simple valid
FOXML to the (example) http://fedorabox:8080/fedora/objects/newpid:foobar
URI and am running into problems.

The first time I attempt to do the POST, I get the error "The PID
'newpid:foobar' already exists in the registry; the object can't be re-
created." even though it is a brand new object. However, if I search
Fedora for the object, I do find it was created. When I look through
the logs, I see that Fedora tries to create the object twice with this
one request.

If I try to POST a second object with a new pid and new FOXML, the
requests succeeds without error. Fedora only tries the ingest once.

My guess is that the initial authentication handshake with the first
POST causes Fedora to attempt the ingest twice. The second POST
succeeds since the browser is already authenticated, and doesn't need
to go through the handshake. I ran into this because I have some
client software that authenticates with every post (since it's not a
browser) and I keep running into this problem. I did not have this
issue with 3.0 or 3.1. I have included the stacktrace error below.

Has anyone else run into this? Any help appreciated.

Thanks,
Willy

javax.ws.rs.WebApplicationException:
fedora.server.errors.ObjectExistsException: The PID 'newpid:foobar'
already exists in the registry; the object can't be re-created.
at
fedora
.server.rest.BaseRestResource.handleException(BaseRestResource.java:122)
at
fedora
.server
.rest.FedoraObjectResource.createObject(FedoraObjectResource.java:416)
at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source)
at
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com
.sun
.jersey.server.impl.model.method.dispatch.EntityParamDispatchProvider
$ResponseOutInvoker._dispatch(EntityParamDispatchProvider.java:157)
at
com
.sun
.jersey
.server
.impl
.model
.method
.dispatch
.ResourceJavaMethodDispatcher
.dispatch(ResourceJavaMethodDispatcher.java:67)
at
com
.sun
.jersey
.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:124)
at
com
.sun
.jersey
.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:
71)
at
com
.sun
.jersey
.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:
111)
at
com
.sun
.jersey
.server
.impl
.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:
63)
at
com
.sun
.jersey
.server
.impl
.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:
555)
at
com
.sun
.jersey
.server
.impl
.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:
514)
at
com
.sun
.jersey
.server
.impl
.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:
505)
at
com
.sun
.jersey
.spi.container.servlet.ServletContainer.service(ServletContainer.java:
359)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
269)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
fedora
.server
.security
.servletfilters.FilterRestApiFlash.doFilter(FilterRestApiFlash.java:78)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
215)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
fedora
.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:
234)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
215)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
fedora
.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:
234)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
215)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
fedora
.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:
234)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
215)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
fedora
.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:
234)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
215)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org
.apache
.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
210)
at
org
.apache
.catalina.core.StandardContextValve.invoke(StandardContextValve.java:
174)
at
org
.apache
.catalina
.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at
org
.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
127)
at
org
.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
117)
at
org
.apache
.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
151)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
870)
at org.apache.coyote.http11.Http11BaseProtocol
$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at
org
.apache
.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at
org
.apache
.tomcat
.util
.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:
81)
at org.apache.tomcat.util.threads.ThreadPool
$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Thread.java:619)
Caused by: fedora.server.errors.ObjectExistsException: The PID
'newpid:foobar' already exists in the registry; the object can't be re-
created.
at
fedora
.server.storage.DefaultDOManager.getIngestWriter(DefaultDOManager.java:
909)
at
fedora
.server.management.DefaultManagement.ingest(DefaultManagement.java:136)
at sun.reflect.GeneratedMethodAccessor111.invoke(Unknown Source)
at
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
fedora
.server
.messaging
.NotificationInvocationHandler
.invoke(NotificationInvocationHandler.java:70)
at $Proxy0.ingest(Unknown Source)
at
fedora.server.management.ManagementModule.ingest(ManagementModule.java:
338)
at
fedora
.server
.rest.FedoraObjectResource.createObject(FedoraObjectResource.java:411)
... 44 more

[Bill Branan]

Hi Willy,

I just tried this and didn't have any problems. I restarted the server (to make sure there were no lingering sessions) then used Poster to POST to the URL you indicated (different host) with some simple FOXML. I was prompted for authentication by Firefox, followed by a 200 response.

You mentioned that Fedora appears to be attempting to create the object twice. Does the first attempt to create the object occur before you submit the authentication prompt? Is the object created correctly on the first attempt, or is it just an empty object that happens to have the correct PID?

Here is the FOXML I used, just for reference:

<?xml version="1.0" encoding="UTF-8"?>

<foxml:digitalObject VERSION="1.1" PID="newpid:foobar" xmlns:foxml="info:fedora/fedora-system:def/foxml#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="info:fedora/fedora-system:def/foxml# http://www.fedora.info/definitions/1/0/foxml1-1.xsd">

<foxml:objectProperties>

<foxml:property NAME="info:fedora/fedora-system:def/model#state" VALUE="Active"/>

<foxml:property NAME="info:fedora/fedora-system:def/model#label" VALUE="Label"/>

</foxml:objectProperties>

</foxml:digitalObject>

Bill

[Ricardo Borillo]

Hi Willy,

Do you have Firebug extension installed? If so, Can you disable it and
retry your tests?
In some situations Firebug can cause a "double post" effect:

http://groups.google.com/group/firebug/browse_thread/thread/8e2a81e41de7f494

---
Salut,
====================================
Ricardo Borillo Domenech
http://xml-utils.com

> ------------------------------------------------------------------------------
>
> _______________________________________________
> Fedora-commons-users mailing list
> Fedora-com...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>
>

[Willy Mene]

Hi Bill,

The first attempt to create the object occurs before I submit the authentication prompt.  It is a complete object with the correct PID.  I have included a sanitized snippet of the server log when the object is first created, but before clicking submit at the authentication prompt and another snippet after authentication is submitted.

Is there some kind of configuration problem on my end?  Thanks Bill!

Willy

[Willy Mene]

Ok, I think I found the problem.

If your http client uses preemptive authorization (i.e. the Authorization http header is sent with the encoded username and password even before the server gives an unauthorized response) , then everything works fine.

However, if you client does not send this header in the initial request and http challenge/response authentication comes into play, then we run into this issue of attempted double object creation.  With the initial request, Fedora always enters the ingest process and creates the object BEFORE the authorization challenge is sent to the client.  Therefore, when the client sends the authorization response, Fedora finds that the object was already created and we see this error.  You can see this in the snippet of the log I sent earlier.

Fedora 3.1 was working with non-preemptive authorization.  Did something change in 3.2?

Willy

[Asger Blekinge-Rasmussen]

Hi

Does this in fact mean that you can ingest objects without a valid
authentication? Your explanation seems to indicate this. This, I would
think, is a serious bug.

Regards

[Bill Branan]

Hi Willy,

When the first, unauthenticated, request is passed in it should be caught and rejected during the authorization check, since there is no available user. Do you happen to have your XACML policies set in such a way that would allow any user to perform an ingest function?

Of course, the unauthenticated call should not be passed through in the first place. We're still trying to reproduce this. Could you tell us a bit more about your environment?

Has anyone else seen this behavior?

Thanks,

Bill

[Chris Wilper]

Hi Willy,

I was unable to reproduce this also...looks like we need more detail
on the environment where this is happening. Although we haven't been
able to verify it yet, I figured it'd be good to put this in the
tracker:

http://fedora-commons.org/jira/browse/FCREPO-510

Can you attach your install.properties and any more detail you have on
your environment there?

Thanks,
Chris

[Willy Mene]

Hey guys,

Ok, I've attached a sanitized install.properties file from this box to
the JIRA issue. It is a test box, so we've turned off XACML policy
enforcement and the API-M SSL requirement. Maybe it is some kind of
configuration issue on our end. Let me know if you need any more info.

Thanks,
Willy

[Bill Branan]

Hi Willy,

I tracked this down and fixed it in trunk a short while ago. It was a bug that let requests through even when authentication was required, as you indicated. This only became obvious when policy enforcement was turned off, because otherwise the authorization check would stop the request from completing.

I don't recommend pulling down and running from trunk at the moment. It does work, but we're in the process of transitioning to maven, so trunk is still being resorted. What you can do is grab the file I updated as the fix (just one file) from here: http://fedora-commons.svn.sourceforge.net/viewvc/fedora-commons/fedora/trunk/server/src/main/java/fedora/server/security/servletfilters/FilterRestApiAuthn.java?revision=8094&view=markup&sortby=date. Then just replace the file in a source distribution of 3.2 and rebuild. The file to replace is fedora.server.security.servletfilters.FilterRestApiAuthn.java.

Thanks for pointing this one out.

Bill

[Asger Blekinge-Rasmussen]

Hi Bill

This sound like a quite serious security hole to me. We run our Fedora
servers without policy enforcement, as we do authentication in another
system. How about making a 3.2.1 Release, just with this fix, it is that
serious.

Could you link this fix to a Bug, and possibly a patch. I am interested
in which versions of Fedora this bug is present for example.

It seems that if you have REST enabled without policies, all API-M
methods are freely available without authentication through REST. I
presume that the same bug does not affect the SOAP layer?

Regards

[Bill Branan]

Hi Asger,

Thanks for pointing out the seriousness of this issue. I imagine that you saw the recent 3.2.1 release announcement (http://fedora-commons.org/confluence/display/FCKB/mail/12321533). There is a patch noted in the email to fix existing 3.1 and 3.2 repositories, the bug doesn't show up prior to 3.1. 

This issue was tracked is here: http://fedora-commons.org/jira/browse/FCREPO-510. You're right that this bug did not affect the SOAP API as it was an issue with the authN servlet filter covering the REST API only.

Bill