[ASP] Download link verbergen

[Brynnie]

Ik moet op een website bepaalde bestanden (zip, exe, ...) beschikbaar maken om gedownload te worden.

Het probleem is dat de locatie van die bestanden niet mag gekend zijn door de bezoeker. Elk bestand staat als link in een dbase (ms sql) en heeft een uniek id.

Nu wou ik een kleine pagina maken bvb download.asp, die dan aan de hand van de querystring wist over welke file het ging en de gebruiker adhv response.redirect(downloadfile_locatie) doorstuurt.

Maar ook al bevat de var downloadfile_locatie de geldige locatie bevat, doet die response.redirect niets. Blijkbaar werkt response.redirect enkel voor html, htm, asp files en dergelijke?

Maar zelfs al mocht dat werken, dan heb ik nog een probleem:

Dan ziet de gebruiker immers de bestandsnaam en locatie in het gepresenteerde download venster van IE.

Met andere woorden: Weet iemand (in asp) hoe ik een download kan "aanbieden" zonder dat de gebruiker kan te weten komen van waar de file gedownload wordt, en indien mogelijk, onder een andere naam.

Zodat bvb file123 niet als file123.zip gedownload wordt, maar als bestand.zip.

't Is een verdraaid vervelend probleem en ik hoop echt dat hier brains rondhangen die mij kunnen helpen...

[tomato]

Lees in je download.asp het hele bestand in en stuur dat door naar de browser. Zorg er wel voor dat je het juiste mime type mee stuurt zodat hij gaat downloaden en niet allemaal rare tekentjes op het scherm zet

[Brynnie]

Is niet echt een oplossing, want het dient gebruikt te worden op een intranet en sommige bestanden zijn tientallen MB groot.

[tomato]

Op zaterdag 10 november 2001 04:09 schreef Brynnie het volgende:
Is niet echt een oplossing, want het dient gebruikt te worden op een intranet en sommige bestanden zijn tientallen MB groot.

Sow
Wat denk je dat er meer gebeurt dan wanneer je 'gewoon' een bestand download?

[dusty]

IK gebruik een download manager, zodra ik een file binnenkrijg zie ik netjes in mijn download manager waar exact die file staat.

Dus je MOET dat accepteren, of je moet inderdaad eerst alles inlezen in dje download pagina en dan uitvoeren naar de gebruiker, Maarja dat loopt op he, aangezien je dan eerst "download" naar je server en dan "upload" naar de gebruiker.

Echter als het op je intranet is, is dit helemaal niet zo erg, immers zullen ze toch in de zelfde range staan en zal het niet zoveel impact hebben op het gehele netwerk.

Als je nou bijvoorbeeld een warez site zou proberen te runnen op het internet zou het opeens wel lastig worden aangezien jij per Gig moet gaan betalen en dan zou je opeens per 1Mb een transfer van 2Mb hebben. (1Mb naar de server, 1Mb naar de gebruiker), Daartegen over zou staan dat dat ook dan gezien kan worden als Hosting van de files. (want die komen immers van jouw server af) wat dus illegaal is. Dus dat zou hetzelfde zijn als de files op je eigen site hosten, Zou je linken naar een andere site dan ia het niet "illegaal" echter dan kan men altijd er weer achterkomen waar het echt vandaan komt (bijvoorbeeld met een download manager..)

[Dennis]

Op zaterdag 10 november 2001 09:54 schreef dusty het volgende:

Wat een vaag verhaal.

[mocean]

Je kan in ASP inderdaad een binairy read doen, en die weer naar de client schrijven.

Je moet dan wel de goede mimetype instellen (in de header meen ik) voor zip / exe etc.

Ik weet niet wat voor server je hebt, maar mischien krijg je met IIS geheugenproblemen wanneer je 30 MB of zo inlaadt om weer naar de client te sturen.

[Crazy D]

Op zaterdag 10 november 2001 09:58 schreef dennisdotcom het volgende:
Wat een vaag verhaal.

't is nog vroeg
Maar hij heeft wel gelijk, je ziet gewoon altijd waar de file vandaan komt. Welkom op het internet
Dus het is of accepteren dat je die url ziet, of zelf bestand inlezen en binair uitspugen...
(wel een goeie reden om de webserver een berg extra RAM te geven )

[Ramon]

waarom zou je dat eigenlijk willen?

[RedHat]

PHP:

<?
$download = "programma.exe";
$decode = base64_decode ("$download");
if ($action == 'download') {
   $encode = base64_encode ("$download");
   fopen ("$download");
}
?>

zoiets zou het dan worden, oja, ik garanteer niet dat het werkt

[Verwijderd]

Op zaterdag 10 november 2001 12:49 schreef Wesley het volgende:
....
zoiets zou het dan worden, oja, ik garanteer niet dat het werkt

Dan garandeer ik dat het zeker niet werkt. Er staat toch echt ASP en geen PHP

[RedHat]

Op zaterdag 10 november 2001 13:01 schreef ml1 het volgende:

[..]

Dan garandeer ik dat het zeker niet werkt. Er staat toch echt ASP en geen PHP

oops, mijn excusses!
zal wel met m'n aars uit dit topic gaan

[Verwijderd]

Op zaterdag 10 november 2001 12:49 schreef Wesley het volgende:

PHP:

<?
$download = "programma.exe";
$decode = base64_decode ("$download");
if ($action == 'download') {
   $encode = base64_encode ("$download");
   fopen ("$download");
}
?>

zoiets zou het dan worden, oja, ik garanteer niet dat het werkt

toch thnxs dit kan ik wel gebruike

[Verwijderd]

Als je lui bent, maak je voor elk bestand in de database een .asp pagina met een server-side include (deze genereer je natuurlijk). MIME type nog wel even zetten natuurlijk:
[code]<%@language=javascript%>
<%
Response.ContentType='image/x-psd'; //photoshop bestanden zijn groot
%>
<!--#INCLUDE FILE="c:\Uw Documenten\groot.psd"-->[code]

Maar lezen en dan een binary-write kan ook wel efficient. Gewoon een loopje van bijv. 2048 bytes schrijven (Response.BinaryWrite) en dan een Response.Flush

Hoe denk je dat IIS zelf bestanden verwerkt?

(Overigens, die server-side include heeft als voordeel dat IIS het bestand kan cachen).

[Mart!]

Misschien kun je eens denken aan een geheel andere inslag. Het gaat er denk ik om dat de gebruiker (of later een andere) niet opnieuw het bestand van dezelfde directory kan downloaden. Mijn idee:

• Zet alle mogelijke te downloaden bestanden in een directory, deze hoeft niet beschikbaar te zijn via HTTP
• Als een gebruiker een bestand opvraagt (wil downloaden):
• Maak een random directory aan die wel via HTTP kan worden benaderd
• Copy (of move is wellicht sneller) de file naar deze directory en geef deze als link
• Als de gebruiker van de pagina af gaat (JS close event oid) dan open je een windowtje met asp-code om het bestand weer te verwijderen/verplaatsen naar de oude lokatie
• Daarna nog een beetje fine tunen, maar dat laat ik aan jou over.

ps. sorry voor de late post, maar ik zie nog niet dat je het probleem hebt opgelost, en bovenstaande heb ik al eens gebruikt