CreateDirectory Webservice definiton

[GoogleCodeExporter]

Feature I would like to see:

 FileConnector to provide APIs for creating and deleting of directories.

Impact if not implemented:

 For our current project, automation of creation and deletion of directories is a key feature. This will remove the necessity of operations team to create the directories manually. 

Alternatives:

 Write bespoke code using ws-apps component.

Original issue reported on code.google.com by phanisri...@gmail.com on 7 Feb 2011 at 6:03

[GoogleCodeExporter]

Assigned ticket to Phani

Original comment by ma...@vandeveen.com on 7 Feb 2011 at 7:26

[GoogleCodeExporter]

Please apply changes in a seperate branch and ask a code review from 
Philip/Ananatha before merging it into trunk. 

Original comment by ma...@vandeveen.com on 7 Feb 2011 at 7:41

[GoogleCodeExporter]

Hi Philip/Anantha

 The attached document has New Webservice's documentation. Please review it let me know your comments. I wanted to check if the webservice definition is inline with other FileConnector webservices.

Original comment by phanisri...@gmail.com on 9 Feb 2011 at 9:31

• Changed title: CreateDirectory Webservice definiton

Attachments:

• [New FC WebServices.doc](https://storage.googleapis.com/google-code-attachments/cordysfilecon/issue-13/comment-3/New FC WebServices.doc)

[GoogleCodeExporter]

Phani,

The services look ok. Keep in mind though that the path that you take in the 
parameter as base folder must matched as a 'valid' location based on the 
configuration of the connector. Otherwise you're exposing a backdoor to a 
server.

Same of course goes for the DeleteDirectory. I think maybe the DeleteDir web 
service should either go in a separate method set or by default block that 
method. And add an additional role which has access to the delete method. Since 
the delete method COULD disrupt the system.

Original comment by pgus...@gmail.com on 10 Feb 2011 at 6:46

[GoogleCodeExporter]

Philip,

Thanks for your comments

1. "'valid' location based on the configuration of the connector" , Do you mean 
to take input from the connector configuration screen

2. For DeleteDirectory API I was also having the same feeling. As it is quite 
powerful, it could be easily misused. I am thinking of implementing only when 
it is requested. 

Original comment by phanisri...@gmail.com on 10 Feb 2011 at 8:44

[GoogleCodeExporter]

What I mean with point 1 is that in the configuration of the file connector you 
can configure the 'allowed paths'. In other words: which folders are 'open' to 
be accessed by the file connector. The Create/Delete Dir should obey that 
configuration.

Original comment by pgus...@gmail.com on 10 Feb 2011 at 9:09

[GoogleCodeExporter]

That is a very good approach. I would say that it is applicable for delete API 
as well. 
For Delete API, it is allowed to delete only empty directories. So in this way, 
at-least it can be less harmful.By default all the APIs are blocked. So I 
believe, for delete if they need to block further, it can be set on DeleteDir 
Operation. We can mention in the document about the security aspect as well. 

Original comment by phanisri...@gmail.com on 14 Feb 2011 at 11:10

[GoogleCodeExporter]

 For the CreateDirectory API enhancement 
Merged the FileConnector trunk with the CreateDirectory API changes in the 
enhancement_12_13 branch
Updated Changelog.xml 

I have not taken the release of the connector. Waiting for PD for a workaround 
for a bug for Node.getData() API for UTF-8 support. So if we dont get that 
workaround, I will have to change coelib and update the coelib jar. 
So I will wait for that couple of more days. 

Original comment by phanisri...@gmail.com on 16 Feb 2011 at 1:14