You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Florent Guillaume <fg...@nuxeo.com> on 2010/11/22 11:44:07 UTC
AD2 and checkin
Hi,
Adobe Drive 2 does the following when you request a checkout:
POST /.../repo/checkedout
Content-Type: application/atom+xml;type=entry
<atom:entry xmlns:atom="http://www.w3.org/2005/Atom">
...
<atom:content
src="http://localhost.../.../repo/content?id=5f8a7a2e-6175-4111-84a3-f70e2d83702e"
type="image/jpeg" />
<cmisra:object
xmlns:cmisra="http://docs.oasis-open.org/ns/cmis/restatom/200908/">
...
</cmisra:object>
...
</atom:entry>
In particular it provides a content src (the one from the entry
itself), which OpenCMIS doesn't like:
HTTP/1.1 405 Method Not Allowed
This is due to code in AtomEntryParser.parseAtomContent:
} else if (ATTR_SRC.equals(attrName.getLocalPart())) {
throw new CmisNotSupportedException("External content
not supported!");
}
I'm not sure this is the right thing to do here, can we just ignore
this external content?
Florent
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
Re: AD2 and checkin
Posted by Florian Müller <fl...@alfresco.com>.
If we remove the exception, a document would be created without content.
Wouldn't that be confusing? It wouldn't really "work".
- Florian
On 22/11/2010 15:32, Florent Guillaume wrote:
> I understand the security implications in implementing this and I
> agree it shouldn't be done at least by default.
> My question was more along the lines of: is it ok if I remove the
> thrown exception so that OpenCMIS-based servers can work with AD2?
>
> Florent
>
>
> On Mon, Nov 22, 2010 at 3:44 PM, Florian Müller
> <fl...@alfresco.com> wrote:
>> Hi Florent,
>>
>> I intentionally didn't implement that features because there are too many difficult questions.
>> What basically happens here is that the CMIS repository connects to a HTTP server to get the content.
>>
>> - In many enterprise environments that's not possible because of firewalls. The server can't talk to an arbitrary host for security reasons.
>>
>> - If the content is hosted on a client machine, it is even more unlikely since desktop firewalls will prevent that.
>>
>> - Should the CMIS repository forward the given credentials to the HTTP server? Hell, no, that would be a security hole. But, yes, it has to authenticate in order to get access to the content...
>>
>> - If we forward the credentials, we really, really should use HTTPS. Do we accept self-signed certificates? Probably not. Does the HTTP server running on a users laptop has a real certificate installed? Probably not.
>>
>> - What if the credentials for the CMIS repository and the HTTP server are different? A very likely scenario...
>>
>> - What if the credentials are not user/password based and we can't forward them because we don't know them?
>>
>>
>> I don't know how to provide a generic external content implementation, but I'm open for ideas...
>>
>>
>> - Florian
>>
>>
>> On 22/11/2010 10:44, Florent Guillaume wrote:
>>> Hi,
>>>
>>> Adobe Drive 2 does the following when you request a checkout:
>>>
>>> POST /.../repo/checkedout
>>> Content-Type: application/atom+xml;type=entry
>>>
>>> <atom:entry xmlns:atom="http://www.w3.org/2005/Atom">
>>> ...
>>> <atom:content
>>> src="http://localhost.../.../repo/content?id=5f8a7a2e-6175-4111-84a3-f70e2d83702e"
>>> type="image/jpeg" />
>>> <cmisra:object
>>> xmlns:cmisra="http://docs.oasis-open.org/ns/cmis/restatom/200908/">
>>> ...
>>> </cmisra:object>
>>> ...
>>> </atom:entry>
>>>
>>> In particular it provides a content src (the one from the entry
>>> itself), which OpenCMIS doesn't like:
>>> HTTP/1.1 405 Method Not Allowed
>>>
>>> This is due to code in AtomEntryParser.parseAtomContent:
>>> } else if (ATTR_SRC.equals(attrName.getLocalPart())) {
>>> throw new CmisNotSupportedException("External content
>>> not supported!");
>>> }
>>>
>>> I'm not sure this is the right thing to do here, can we just ignore
>>> this external content?
>>>
>>> Florent
>>>
>>>
>>>
>>
>>
>
>
>
Re: AD2 and checkin
Posted by Florent Guillaume <fg...@nuxeo.com>.
I understand the security implications in implementing this and I
agree it shouldn't be done at least by default.
My question was more along the lines of: is it ok if I remove the
thrown exception so that OpenCMIS-based servers can work with AD2?
Florent
On Mon, Nov 22, 2010 at 3:44 PM, Florian Müller
<fl...@alfresco.com> wrote:
> Hi Florent,
>
> I intentionally didn't implement that features because there are too many difficult questions.
> What basically happens here is that the CMIS repository connects to a HTTP server to get the content.
>
> - In many enterprise environments that's not possible because of firewalls. The server can't talk to an arbitrary host for security reasons.
>
> - If the content is hosted on a client machine, it is even more unlikely since desktop firewalls will prevent that.
>
> - Should the CMIS repository forward the given credentials to the HTTP server? Hell, no, that would be a security hole. But, yes, it has to authenticate in order to get access to the content...
>
> - If we forward the credentials, we really, really should use HTTPS. Do we accept self-signed certificates? Probably not. Does the HTTP server running on a users laptop has a real certificate installed? Probably not.
>
> - What if the credentials for the CMIS repository and the HTTP server are different? A very likely scenario...
>
> - What if the credentials are not user/password based and we can't forward them because we don't know them?
>
>
> I don't know how to provide a generic external content implementation, but I'm open for ideas...
>
>
> - Florian
>
>
> On 22/11/2010 10:44, Florent Guillaume wrote:
>> Hi,
>>
>> Adobe Drive 2 does the following when you request a checkout:
>>
>> POST /.../repo/checkedout
>> Content-Type: application/atom+xml;type=entry
>>
>> <atom:entry xmlns:atom="http://www.w3.org/2005/Atom">
>> ...
>> <atom:content
>> src="http://localhost.../.../repo/content?id=5f8a7a2e-6175-4111-84a3-f70e2d83702e"
>> type="image/jpeg" />
>> <cmisra:object
>> xmlns:cmisra="http://docs.oasis-open.org/ns/cmis/restatom/200908/">
>> ...
>> </cmisra:object>
>> ...
>> </atom:entry>
>>
>> In particular it provides a content src (the one from the entry
>> itself), which OpenCMIS doesn't like:
>> HTTP/1.1 405 Method Not Allowed
>>
>> This is due to code in AtomEntryParser.parseAtomContent:
>> } else if (ATTR_SRC.equals(attrName.getLocalPart())) {
>> throw new CmisNotSupportedException("External content
>> not supported!");
>> }
>>
>> I'm not sure this is the right thing to do here, can we just ignore
>> this external content?
>>
>> Florent
>>
>>
>>
>
>
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
Re: AD2 and checkin
Posted by Florent Guillaume <fg...@nuxeo.com>.
Yes, apologies, I initially used a wrong subject. It's about checkout.
Florent
On Tue, Nov 23, 2010 at 8:06 AM, Jens Hübel <jh...@opentext.com> wrote:
> Sorry I missed that the thread continued...
>
> If it is checkout then we should be tolerant regarding non-relevant information in the message bodies imho.
>
> Jens
>
> -----Original Message-----
> From: Jens Hübel [mailto:jhuebel@opentext.com]
> Sent: Dienstag, 23. November 2010 08:03
> To: chemistry-dev@incubator.apache.org
> Subject: RE: AD2 and checkin
>
> I don't get it here. The subject of the mail talks about a checkin operation, the body of the email talks about checkout...
>
>> Adobe Drive 2 does the following when you request a checkout:
>> POST /.../repo/checkedout
>
> If we talk about checkout, I am not sure why the client sends a content link. This would be pretty useless in this case, because creating the PWC is only a task for the server.
>
> So the question then would be: Do we need to throw an exception for useless information that we get? I think reporting a warning to the log file would be sufficient in this case. However if we talk about a checkin (and the client does not transfer content inline but refers to a foreign destination) then all the issues Florian reports can't be silently ignored...
>
> Florent could you clarify the use case?
>
> Jens
>
>
>
> -----Original Message-----
> From: Florian Müller [mailto:florian.mueller@alfresco.com]
> Sent: Montag, 22. November 2010 15:45
> To: chemistry-dev@incubator.apache.org
> Subject: Re: AD2 and checkin
>
> Hi Florent,
>
> I intentionally didn't implement that features because there are too many difficult questions.
> What basically happens here is that the CMIS repository connects to a HTTP server to get the content.
>
> - In many enterprise environments that's not possible because of firewalls. The server can't talk to an arbitrary host for security reasons.
>
> - If the content is hosted on a client machine, it is even more unlikely since desktop firewalls will prevent that.
>
> - Should the CMIS repository forward the given credentials to the HTTP server? Hell, no, that would be a security hole. But, yes, it has to authenticate in order to get access to the content...
>
> - If we forward the credentials, we really, really should use HTTPS. Do we accept self-signed certificates? Probably not. Does the HTTP server running on a users laptop has a real certificate installed? Probably not.
>
> - What if the credentials for the CMIS repository and the HTTP server are different? A very likely scenario...
>
> - What if the credentials are not user/password based and we can't forward them because we don't know them?
>
>
> I don't know how to provide a generic external content implementation, but I'm open for ideas...
>
>
> - Florian
>
>
> On 22/11/2010 10:44, Florent Guillaume wrote:
>> Hi,
>>
>> Adobe Drive 2 does the following when you request a checkout:
>>
>> POST /.../repo/checkedout
>> Content-Type: application/atom+xml;type=entry
>>
>> <atom:entry xmlns:atom="http://www.w3.org/2005/Atom">
>> ...
>> <atom:content
>> src="http://localhost.../.../repo/content?id=5f8a7a2e-6175-4111-84a3-f70e2d83702e"
>> type="image/jpeg" />
>> <cmisra:object
>> xmlns:cmisra="http://docs.oasis-open.org/ns/cmis/restatom/200908/">
>> ...
>> </cmisra:object>
>> ...
>> </atom:entry>
>>
>> In particular it provides a content src (the one from the entry
>> itself), which OpenCMIS doesn't like:
>> HTTP/1.1 405 Method Not Allowed
>>
>> This is due to code in AtomEntryParser.parseAtomContent:
>> } else if (ATTR_SRC.equals(attrName.getLocalPart())) {
>> throw new CmisNotSupportedException("External content
>> not supported!");
>> }
>>
>> I'm not sure this is the right thing to do here, can we just ignore
>> this external content?
>>
>> Florent
>>
>>
>>
>
>
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
RE: AD2 and checkin
Posted by Jens Hübel <jh...@opentext.com>.
Sorry I missed that the thread continued...
If it is checkout then we should be tolerant regarding non-relevant information in the message bodies imho.
Jens
-----Original Message-----
From: Jens Hübel [mailto:jhuebel@opentext.com]
Sent: Dienstag, 23. November 2010 08:03
To: chemistry-dev@incubator.apache.org
Subject: RE: AD2 and checkin
I don't get it here. The subject of the mail talks about a checkin operation, the body of the email talks about checkout...
> Adobe Drive 2 does the following when you request a checkout:
> POST /.../repo/checkedout
If we talk about checkout, I am not sure why the client sends a content link. This would be pretty useless in this case, because creating the PWC is only a task for the server.
So the question then would be: Do we need to throw an exception for useless information that we get? I think reporting a warning to the log file would be sufficient in this case. However if we talk about a checkin (and the client does not transfer content inline but refers to a foreign destination) then all the issues Florian reports can't be silently ignored...
Florent could you clarify the use case?
Jens
-----Original Message-----
From: Florian Müller [mailto:florian.mueller@alfresco.com]
Sent: Montag, 22. November 2010 15:45
To: chemistry-dev@incubator.apache.org
Subject: Re: AD2 and checkin
Hi Florent,
I intentionally didn't implement that features because there are too many difficult questions.
What basically happens here is that the CMIS repository connects to a HTTP server to get the content.
- In many enterprise environments that's not possible because of firewalls. The server can't talk to an arbitrary host for security reasons.
- If the content is hosted on a client machine, it is even more unlikely since desktop firewalls will prevent that.
- Should the CMIS repository forward the given credentials to the HTTP server? Hell, no, that would be a security hole. But, yes, it has to authenticate in order to get access to the content...
- If we forward the credentials, we really, really should use HTTPS. Do we accept self-signed certificates? Probably not. Does the HTTP server running on a users laptop has a real certificate installed? Probably not.
- What if the credentials for the CMIS repository and the HTTP server are different? A very likely scenario...
- What if the credentials are not user/password based and we can't forward them because we don't know them?
I don't know how to provide a generic external content implementation, but I'm open for ideas...
- Florian
On 22/11/2010 10:44, Florent Guillaume wrote:
> Hi,
>
> Adobe Drive 2 does the following when you request a checkout:
>
> POST /.../repo/checkedout
> Content-Type: application/atom+xml;type=entry
>
> <atom:entry xmlns:atom="http://www.w3.org/2005/Atom">
> ...
> <atom:content
> src="http://localhost.../.../repo/content?id=5f8a7a2e-6175-4111-84a3-f70e2d83702e"
> type="image/jpeg" />
> <cmisra:object
> xmlns:cmisra="http://docs.oasis-open.org/ns/cmis/restatom/200908/">
> ...
> </cmisra:object>
> ...
> </atom:entry>
>
> In particular it provides a content src (the one from the entry
> itself), which OpenCMIS doesn't like:
> HTTP/1.1 405 Method Not Allowed
>
> This is due to code in AtomEntryParser.parseAtomContent:
> } else if (ATTR_SRC.equals(attrName.getLocalPart())) {
> throw new CmisNotSupportedException("External content
> not supported!");
> }
>
> I'm not sure this is the right thing to do here, can we just ignore
> this external content?
>
> Florent
>
>
>
RE: AD2 and checkin
Posted by Jens Hübel <jh...@opentext.com>.
I don't get it here. The subject of the mail talks about a checkin operation, the body of the email talks about checkout...
> Adobe Drive 2 does the following when you request a checkout:
> POST /.../repo/checkedout
If we talk about checkout, I am not sure why the client sends a content link. This would be pretty useless in this case, because creating the PWC is only a task for the server.
So the question then would be: Do we need to throw an exception for useless information that we get? I think reporting a warning to the log file would be sufficient in this case. However if we talk about a checkin (and the client does not transfer content inline but refers to a foreign destination) then all the issues Florian reports can't be silently ignored...
Florent could you clarify the use case?
Jens
-----Original Message-----
From: Florian Müller [mailto:florian.mueller@alfresco.com]
Sent: Montag, 22. November 2010 15:45
To: chemistry-dev@incubator.apache.org
Subject: Re: AD2 and checkin
Hi Florent,
I intentionally didn't implement that features because there are too many difficult questions.
What basically happens here is that the CMIS repository connects to a HTTP server to get the content.
- In many enterprise environments that's not possible because of firewalls. The server can't talk to an arbitrary host for security reasons.
- If the content is hosted on a client machine, it is even more unlikely since desktop firewalls will prevent that.
- Should the CMIS repository forward the given credentials to the HTTP server? Hell, no, that would be a security hole. But, yes, it has to authenticate in order to get access to the content...
- If we forward the credentials, we really, really should use HTTPS. Do we accept self-signed certificates? Probably not. Does the HTTP server running on a users laptop has a real certificate installed? Probably not.
- What if the credentials for the CMIS repository and the HTTP server are different? A very likely scenario...
- What if the credentials are not user/password based and we can't forward them because we don't know them?
I don't know how to provide a generic external content implementation, but I'm open for ideas...
- Florian
On 22/11/2010 10:44, Florent Guillaume wrote:
> Hi,
>
> Adobe Drive 2 does the following when you request a checkout:
>
> POST /.../repo/checkedout
> Content-Type: application/atom+xml;type=entry
>
> <atom:entry xmlns:atom="http://www.w3.org/2005/Atom">
> ...
> <atom:content
> src="http://localhost.../.../repo/content?id=5f8a7a2e-6175-4111-84a3-f70e2d83702e"
> type="image/jpeg" />
> <cmisra:object
> xmlns:cmisra="http://docs.oasis-open.org/ns/cmis/restatom/200908/">
> ...
> </cmisra:object>
> ...
> </atom:entry>
>
> In particular it provides a content src (the one from the entry
> itself), which OpenCMIS doesn't like:
> HTTP/1.1 405 Method Not Allowed
>
> This is due to code in AtomEntryParser.parseAtomContent:
> } else if (ATTR_SRC.equals(attrName.getLocalPart())) {
> throw new CmisNotSupportedException("External content
> not supported!");
> }
>
> I'm not sure this is the right thing to do here, can we just ignore
> this external content?
>
> Florent
>
>
>
Re: AD2 and checkin
Posted by Florian Müller <fl...@alfresco.com>.
Hi Florent,
I intentionally didn't implement that features because there are too many difficult questions.
What basically happens here is that the CMIS repository connects to a HTTP server to get the content.
- In many enterprise environments that's not possible because of firewalls. The server can't talk to an arbitrary host for security reasons.
- If the content is hosted on a client machine, it is even more unlikely since desktop firewalls will prevent that.
- Should the CMIS repository forward the given credentials to the HTTP server? Hell, no, that would be a security hole. But, yes, it has to authenticate in order to get access to the content...
- If we forward the credentials, we really, really should use HTTPS. Do we accept self-signed certificates? Probably not. Does the HTTP server running on a users laptop has a real certificate installed? Probably not.
- What if the credentials for the CMIS repository and the HTTP server are different? A very likely scenario...
- What if the credentials are not user/password based and we can't forward them because we don't know them?
I don't know how to provide a generic external content implementation, but I'm open for ideas...
- Florian
On 22/11/2010 10:44, Florent Guillaume wrote:
> Hi,
>
> Adobe Drive 2 does the following when you request a checkout:
>
> POST /.../repo/checkedout
> Content-Type: application/atom+xml;type=entry
>
> <atom:entry xmlns:atom="http://www.w3.org/2005/Atom">
> ...
> <atom:content
> src="http://localhost.../.../repo/content?id=5f8a7a2e-6175-4111-84a3-f70e2d83702e"
> type="image/jpeg" />
> <cmisra:object
> xmlns:cmisra="http://docs.oasis-open.org/ns/cmis/restatom/200908/">
> ...
> </cmisra:object>
> ...
> </atom:entry>
>
> In particular it provides a content src (the one from the entry
> itself), which OpenCMIS doesn't like:
> HTTP/1.1 405 Method Not Allowed
>
> This is due to code in AtomEntryParser.parseAtomContent:
> } else if (ATTR_SRC.equals(attrName.getLocalPart())) {
> throw new CmisNotSupportedException("External content
> not supported!");
> }
>
> I'm not sure this is the right thing to do here, can we just ignore
> this external content?
>
> Florent
>
>
>