吕宋平 wrote on 05/29/13 21:38:
> Hi, Bill, Craig, Hong,Sahoo:
>
> After the disscusstion recently, I pick up some of the disscussion above
> and list as follows to see whether there still exist any other suggestion:
>
> A) An option to disable the deployuri command completely should the
> administrator be concerned
> B) An option to limit the URI types that would be allowed
> C) Allow for specification of a "sandbox" area use as the download location to
> better control permissions, ownership, quotas, disk space, etc.
> D) Allow for the possibility to include hooks for virus scanners or other
> intrusion detection software.
>
> As to A) and B):
> Just regard the tips as Bill had mentioned that we should create an attribute
> or property set with "asadmin set", If different administrators had different
> privileges in the future, we could restrict the use of the "asadmin set"
> command. I think the most important question here is to how to use a
> local-only command to control this option("asadmin set")?
I can't think of any other cases where we do anything like this, so I'm not sure
we have a precedent to follow. Perhaps someone else here has some ideas?
I think "asadmin set" can be used to modify most anything in domain.xml, so I'm
not sure there's a way to include this configuration information in domain.xml
but hide it from "asadmin set".
Another option is to store this information in a separate config file, and have
a local asadmin command to manipulate that config file. That seems like
overkill, so I'm hoping someone else will have a better idea.
> As to C):
> Regard to the tips as Hong, How about regarding the directory of
> domains/<domain_dir>/applications/__internal/<app_name>/ as a directory to
> store the application download remotely. Of course, the operation to execute
> the download will be executed during the server side.
Does that directory already exist? What's it used for?
I'm still not convinced that we need a special directory just for this purpose.
It seems to me we should be able to reuse an existing directory, either an
existing upload "tmp" directory, or an existing application staging directory.
> As to D):
> Regard the tips as Sahoo suggest, we can try to enforce use of vc like
> protocol or automatically decorate the url with vc protocol
I think that's the wrong approach.
I think we should ignore this issue for now and leave it to a future one-pager.