467,915 Members | 1,541 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,915 developers. It's quick & easy.

Download processing script: is it possible?

Hi!

I am thinking to have a client-side script doing processing on file
downloading, basically the script will process a downloaded file from the
server before it received by the user. For example, the weboage will have
a link to download file A, but the one stored in the server is not exactly
file A, but some transformation of it. If the user click the link, it
activate the script which will actually load the file from the server,
detransform it into the file A, and return the file A to the user (with
correct content-type obviously). The transformation can be an encryption,
or the file broken into multiple segments.

Is this possible to do using client-side javascript?

The idea seems to be similar to soem image rollover script, which load the
image from server and then display it dynamically. Except that it seems
that Image objects don't have any properties that actually represent the
image data itself.

If it is possible, any hint where to begin?

Thanks!

--
Stephan Paul Arif Sahari Wibowo
_____ _____ _____ _____
/____ /____/ /____/ /____
_____/ / / / _____/ http://www.arifsaha.com/
Jul 23 '05 #1
  • viewed: 1651
Share:
6 Replies
On Sun, 15 Aug 2004 15:42:24 -0400, S P Arif Sahari Wibowo wrote:
basically the script will process a downloaded file from the
server before it received by the user. ... If it is possible, any hint where to begin?
The server. This is easily done in any number
of server side languages. Any arbitrary (valid)
URL/URI can be mapped to perform any number of
complex tasks ((un)encryption/compression/data
collection and packaging, image processing..)
on the server and either feed a '.zip' or whatever
file is most appropriate for the client, back.

By that stage, any client side script is unnecessary,
and irrelevant, as the above can be invoked from a
plain old HTML link.

As an aside, even if you *could* do this in a client
side script, it would be inherently insecure, as
the user can pick the script apart and make direct
requests for the filres. If they are feeling lazy
they may just watch their 'sniffer', which monitors
and reports all traffic between client and server.
_____/ / / / _____/ http://www.arifsaha.com/


BTW. I guess you made your site when looking at
something that supports .PNG transaparency?
In other words, not ..IE (Internet Explorer)
To whit, bottom of your site..

"Any comment? Email the webmaster at 'email address .png'"

The white background appears in IE,
(not in Moz 1.3/Opera 6.5.1 tho'..)

And that address you use, starting with 'www', is
quite couterintuitive. I had to look closely,
before I realized it was followed by
'@' rather than '.'

You counter is broken as well.

Opera reports 'could not retrieve data from server..'
(words to that effect)

HTH

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology
Jul 23 '05 #2
On Mon, 16 Aug 2004, Andrew Thompson wrote:
The server. This is easily done in any number of server side languages.
I know it is easy even trivial in server-side script. If it is that easy,
that's how I will do it. Unfortunately, the particular server have several
limitation that force me to seriously consider client-side solution.

So the question still stand: is it possible to do it as client side
script? Can a client side javascript actually access a file from a server?
Can a client side javascript hand a generated binary content to the user?
As an aside, even if you *could* do this in a client
side script, it would be inherently insecure,
Obviously understandable, in that case the protection should not come from
the algorithm itself, but from a decryption key-phrase. The algorithm
would be useless without the correct key.
If they are feeling lazy they may just watch their 'sniffer', which
monitors and reports all traffic between client and server.
Well, this will break a server-side encryption as well, right?
BTW. I guess you made your site when looking at
something that supports .PNG transaparency?
As PNG is an open standard, I consider browser that doesn't support it as
obsolote. I did try it in IE, and I saw that the information still came
up, so it is still acceptable. Not so bad for an obsolote browser.

The bigger problem is embedded document for counter. I actually want to
use the object tag, but IE doesn't support it. So I was forced to use
iframe (so don't say I cannot make compromise), it still look horrible in
IE, but at least is show up. The current server actually allow me to use
SSI, so I'll put it in as soon as I have time.
And that address you use, starting with 'www', is quite couterintuitive.
I had to look closely, before I realized it was followed by '@' rather
than '.'
Is it? Hmmm... I'll think about it, thanks. I have to avoid the comment
"webmaster" due to amount of spam sent to that address (eventhough I never
use not publicize that address).
You counter is broken as well.
Opera reports 'could not retrieve data from server..'
(words to that effect)


This is specific to Opera, right? Interesting. Do Opera support iframe?

Thanks!

--
Stephan Paul Arif Sahari Wibowo
_____ _____ _____ _____
/____ /____/ /____/ /____
_____/ / / / _____/ http://www.arifsaha.com/
Jul 23 '05 #3
S P Arif Sahari Wibowo wrote:
So the question still stand: is it possible to do it as client side
script?
Yes, but not reliably.
Can a client side javascript actually access a file from a server?
Of itself: Not directly. It can request a resource from a server via HTTP.
The difference is that the resource may not reflect the contents of a file
on the server's filesystem but something generated, possibly including
data from a file, usually a database, and the request may result in
certain server-side actions if it triggers a server-side application.

Using an appropriate host object: Yes.
Can a client side javascript hand a generated binary content to the user?
Unless there is an appropriate host object, it cannot. Such an object
would be probably provided by ActiveX and/or Java which would decrease
the reliability of the script (and AFAIK restrict usage to IE 4+ on 32
bit Windows). I have seen a Java downloader object accessed with ActiveX
in IE 5.5+ on Windows 98/2000.
As an aside, even if you *could* do this in a client
side script, it would be inherently insecure,


Obviously understandable, in that case the protection should not come from
the algorithm itself, but from a decryption key-phrase. The algorithm
would be useless without the correct key.


I am not sure if you have understood that any algorithm used in client-side
scripts must be served along with the data it is operating on.
If they are feeling lazy they may just watch their 'sniffer', which
monitors and reports all traffic between client and server.


Well, this will break a server-side encryption as well, right?


Not quite as fast. HTTPS uses SSL/TLS which uses strong encryption
algorithms that can be considered quite secure these days, taking the
quite high effort/revenue ratio for cracking them into account.
BTW. I guess you made your site when looking at
something that supports .PNG transaparency?


As PNG is an open standard, I consider browser that doesn't support it as
obsolote. I did try it in IE, and I saw that the information still came
up, so it is still acceptable. Not so bad for an obsolote browser.


<http://libpng.org/pub/png/pngapbr.html>
The bigger problem is embedded document for counter. I actually want to
use the object tag,
You mean the "object" (X)HTML _element_.
but IE doesn't support it.
IE does support it, but not in a standards compliant way.
[...]
And that address you use, starting with 'www', is quite couterintuitive.
I had to look closely, before I realized it was followed by '@' rather
than '.'


Is it? Hmmm... I'll think about it, thanks. I have to avoid the comment
"webmaster" due to amount of spam sent to that address (eventhough I never
use not publicize that address).


You should use a formmailer (server-side SMTP script). It not only prevents
you from getting spam from usual spambots, it also is reliable while the
"mailto:" URI is not.
You counter is broken as well.
Opera reports 'could not retrieve data from server..'
(words to that effect)


This is specific to Opera, right? Interesting. Do Opera support iframe?


<http://www.opera.com/docs/specs/opera6/>
<http://www.opera.com/docs/specs/>
HTH

PointedEars, with appropriate random sig
--
One hundred security holes in the code, one hundred security holes...
Jul 23 '05 #4
On Mon, 16 Aug 2004, Thomas 'PointedEars' Lahn wrote:
Yes, but not reliably.
Can it be done using javascript (without depending to other client-side
scripting)?
Of itself: Not directly. It can request a resource from a server via
HTTP.
That's Ok. I didn't expect more. How to do that?
Unless there is an appropriate host object, it cannot.
Is there any host object for binary files available from the browser
itself? If I have to use Java to create the host object, it is probably
better just use java for the whole thing, right?
I am not sure if you have understood that any algorithm used in
client-side scripts must be served along with the data it is operating
on.
Well, yes, I understand completely. What I mean is although the script is
open, it cannot be use to decrypt the data without correct key (provided
by user).
Not quite as fast. HTTPS uses SSL/TLS which uses strong encryption
algorithms that can be considered quite secure these days, taking the
quite high effort/revenue ratio for cracking them into account.
If the server have SSL... as I said, this server have many limitation.
<http://libpng.org/pub/png/pngapbr.html>
Ok, other than obsolote browsers, some broken ones, too. :-)
You mean the "object" (X)HTML _element_.
Yes.
IE does support it, but not in a standards compliant way.
So IE doesn't support the standards compliant ones. :-)
You should use a formmailer (server-side SMTP script). It not only
prevents you from getting spam from usual spambots, it also is reliable
while the "mailto:" URI is not.
Yes I should, when I get around to it. For now, I just use the image.
<http://www.opera.com/docs/specs/opera6/>


Well, it do support it. Don't understand the problem, then. Will get back
to it later when I have Opera to work with.

Thanks!

--
Stephan Paul Arif Sahari Wibowo
_____ _____ _____ _____
/____ /____/ /____/ /____
_____/ / / / _____/ http://www.arifsaha.com/
Jul 23 '05 #5
S P Arif Sahari Wibowo wrote:
On Mon, 16 Aug 2004, Thomas 'PointedEars' Lahn wrote:
Yes, but not reliably.
Can it be done using javascript (without depending to other client-side
scripting)?


Depends. What do you mean with "other client-side scripting"?
Of itself: Not directly. It can request a resource from a server via
HTTP.


That's Ok. I didn't expect more. How to do that?


Read on the `location' property and XMLHttpRequest (Google is your friend.
[psf 6.1]) Note, though, that the latter interface requires one of the
more recent user agents; in IE, it also requires ActiveX support to be
present and enabled (which AFAIK is only possible in 32 bit Windows).
Unless there is an appropriate host object, it cannot.


Is there any host object for binary files available from the browser
itself?


That depends on the browser, its version, security settings and the
operating system and platform it is running on.
If I have to use Java to create the host object, it is probably
better just use java for the whole thing, right?


Well, yo/nes ;-) Client-side Java is running in a sandbox even more
restricted than client-side J(ava)Script. If you assume that the
Java sandbox is not too much restricted due to low security settings,
it can be done.
I am not sure if you have understood that any algorithm used in
client-side scripts must be served along with the data it is operating
on.


Well, yes, I understand completely. What I mean is although the script is
open, it cannot be use to decrypt the data without correct key (provided
by user).


Ahhh, but somehow you must determine if the key was correct.
PointedEars
--
When you're younger you can eat what you like, drink what you like and
still climb into your 25 inch waist trousers and zip them closed. Then
you reach that age - 24,25 - your muscles give up, they wave a little
white flag and without any warning at all you're suddenly a fat bastard.
Jul 23 '05 #6
On Mon, 16 Aug 2004 16:06:56 -0400, S P Arif Sahari Wibowo wrote:

(my reply is based on this post only, my feed to
usenet is completely f**ked up at the moment and
posts are trickling through, out of order.)
If I have to use Java to create the host object, it is probably
better just use java for the whole thing, right?


It is probably better to stick with pure Java
*or* pure JS on the client browser for the simple
reason that gives you a greater userbase. There are
'Java/No JS', as well as 'non-Java/JS' users out there..
Also, I learned just the other day that Applets operated
via JS automatically get a more restricted security
environment.

You now seem convinced there is no security
problem, but I have not seen enough to convince me.

As such, I will comment that any security holes
that may be inherent in providing the client
(or any cracker, posing as a client) with the
JS, are also applicable to supplying a Java Applet.

To crack a Java applet simply requires two more
steps. Unpacking the 'jar'd file using WinZip.
Running a utility to convert the bytecodes back to
human readable form.

In all other respects, cracking Java/JS
are roughly the same. Both can be obfuscated,
or otherwise written in counter-intuitive ways.

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology
Jul 23 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Kornelius Finkenbein | last post: by
2 posts views Thread by mike_j | last post: by
8 posts views Thread by William Starr Moake | last post: by
reply views Thread by Chuck Anderson | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.