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
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?
On Fri, 2009-06-26 at 21:24 +0200, Bill Branan wrote:
> 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.
> On Thu, Jun 25, 2009 at 5:30 PM, Willy Mene <email@example.com>
> 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.
> On Jun 25, 2009, at 12:37 PM, Chris Wilper wrote:
> 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
> Can you attach your install.properties and any more
> detail you have on
> your environment there?
> On Thu, Jun 25, 2009 at 9:30 AM, Bill
> Branan<firstname.lastname@example.org> wrote:
> 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?
> On Wed, Jun 24, 2009 at 8:45 PM, Willy Mene
> <email@example.com> wrote:
> 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
> 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
> authorization challenge is sent to the
> client. Therefore, when the client
> sends the authorization response,
> Fedora finds that the object was
> created and we see this error. You
> can see this in the snippet of the log
> sent earlier.
> Fedora 3.1 was working with
> non-preemptive authorization. Did
> change in 3.2?
> On Jun 24, 2009, at 6:35 AM, Bill
> Branan wrote:
> 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
> 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
> 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
> <?xml version="1.0" encoding="UTF-8"?>
> <foxml:digitalObject VERSION="1.1"
> On Tue, Jun 23, 2009 at 5:41 PM, Willy
> Mene <firstname.lastname@example.org> wrote:
> 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
> FOXML to the (example)
> URI and am running into
> The first time I attempt to do
> the POST, I get the error "The
> '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
> 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
> Has anyone else run into
> this? Any help appreciated.
> fedora.server.errors.ObjectExistsException: The PID 'newpid:foobar'
> already exists in the
> registry; the object can't be
> Fedora-commons-users mailing list