[ASP VB] Shell object uitvoeren: veiligheid?

[Verwijderd]

Wil met een ASP script een bestand kopieëren van de ene FTP locatie naar de andere (twee verschillende servers). Nu werkt dit allemaal erg mooi met FTP.

Stukje relevante code:

code:

Const DOE_FTP = "ftp.exe -i -s:ftp.txt ftpserver.domain.com"
Set Actie = objShell.Exec("DOE_FTP c:\inetpub\map\bestand.txt")

Bij regel 2 krijg ik een foutmelding die te maken heeft met het bestand: WSHOM.OCX. Dit ActiveX bestand is niet geregistreerd en een zoektocht op internet leert dat het niet erg verstandig is.

Toch wil ik gebruik maken van commando's op de server, maar hoe kan ik dit het beste beveiligen? Verschillende rechten aangeven misschien? Als ik het bestand toegang geef tot EVERYONE en full control dan werkt het nog niet.

Iemand ideeën, tips of adviezen?

Ik gebruik Windows 2003 Server

[Verwijderd]

Tis vrij apart als je WScript.Shell object (denk ik toch) niet geregistreerd is. Staat er Internet Explorer op je server? Over de veiligheid durf ik niks te zeggen. Als het goed is zou het niet uit moeten maken... maar ik zou er verschillende uiteindes van mijn lichaam niet voor in het vuur willen steken.

Overigens vermoed ik dat je string niet klopt. Bedoel je niet

code:

Set Actie = objShell.Exec(DOE_FTP)

Ten eerste probeer je nu de letterlijke string

code:

DOE_FTP c:\inetpub\map\bestand.txt

uit te voeren (die doet niks), en zelfs al zou je

code:

DOE_FTP & " c:\inetpub\map\bestand.txt"

gebruiken, doet die extra parameter nog iets bij ftp.exe als je al een script opgeeft?

[ Voor 17% gewijzigd door Verwijderd op 21-07-2004 21:38 ]

[igmar]

Verwijderd schreef op 21 juli 2004 @ 21:28:
Toch wil ik gebruik maken van commando's op de server, maar hoe kan ik dit het beste beveiligen? Verschillende rechten aangeven misschien? Als ik het bestand toegang geef tot EVERYONE en full control dan werkt het nog niet.

Is het niet handiger om FTP vanuit ASP zelf te regelen ? Ik kan me voorstellen dat je als beheerder niet wil dat gebruikers 'gewoon' commando's uitvoeren, en je voorkomt daarmee problemen dat ShellExec() in de toekomst kwa functionaliteit teruggeschroefd gaat worden.