Open and read from http://someserver/file.txt

[Nik Coughin]

Is there a simple way of opening a text file from a server, and reading from
it line by line?

IE

http://someserver/file.txt contains a couple of hundred lines. Each line is
the name of a file. I want to read this list of files into an array of
strings. I don't have any control over the creation of file.txt so I really
need to be able to read from it in it's existing format, a list of files
seperated by carriage returns.

Thanks,

Nik Coughlin

[Vincent van Beveren]

If the text file is on the same server as the JavaScript this might
be possible, else it would probably run into some security issues.
You could attempt to make a hidden IFRAME, load the text file, and read
it by accessing its document.body.i nnerText or something...

<IFRAME SRC="file.txt" ID="myframe" onLoad="readFil e();"
STYLE="visibili ty:hidden;width :0px;height:0px ">
</IFRAME>

function readFile() {
thedoc = document.myfram e.contentWindow .document.body. innerText;
splitted = thedoc.split('\ n');
}

I haven't tested it, but it should be more or less like this. If the
file is on another server, you might need to run it as a signed script
or you'll need some server-side solution.

Good luck,
Vincent

Nik Coughin wrote:

Is there a simple way of opening a text file from a server, and reading from
it line by line?

IE

http://someserver/file.txt contains a couple of hundred lines. Each line is
the name of a file. I want to read this list of files into an array of
strings. I don't have any control over the creation of file.txt so I really
need to be able to read from it in it's existing format, a list of files
seperated by carriage returns.

Thanks,

Nik Coughlin

[Nik Coughin]

Vincent van Beveren wrote:

If the text file is on the same server as the JavaScript this might
be possible, else it would probably run into some security issues.
I don't really understand how it could be an issue. Text file available to
anyone with a browser, how can it be a security issue that my JavaScript can
see it too?

I'm not saying you're wrong, from what I've seen it seems that you're right.
I just *can't* for the life of me see the security issue with JavaScript
being able to access a file that is on the WWW.
You could attempt to make a hidden IFRAME, load the text file, and
read it by accessing its document.body.i nnerText or something...

<IFRAME SRC="file.txt" ID="myframe" onLoad="readFil e();"
STYLE="visibili ty:hidden;width :0px;height:0px ">
</IFRAME>

function readFile() {
thedoc = document.myfram e.contentWindow .document.body. innerText;
splitted = thedoc.split('\ n');
}

I haven't tested it, but it should be more or less like this. If the
file is on another server, you might need to run it as a signed script
or you'll need some server-side solution.

Good luck,
Vincent

Thanks, I'll give it a go. Otherwise I guess it'll have to be server-side.

[Michael Winter]

On Fri, 2 Apr 2004 09:18:26 +1200, Nik Coughin <nr***********@ woosh.co.nz>
wrote:

Vincent van Beveren wrote:

If the text file is on the same server as the JavaScript this might
be possible, else it would probably run into some security issues.

I don't really understand how it could be an issue. Text file available
to anyone with a browser, how can it be a security issue that my
JavaScript can see it too?

I'm not saying you're wrong, from what I've seen it seems that you're
right.
I just *can't* for the life of me see the security issue with JavaScript
being able to access a file that is on the WWW.

Security is privacy oriented. Possibilities.. .

Accessing HTML pages from other domains:

A script could interfere with a page. An extreme case might be one that
periodicly checks other pages for form fields that contain personal
information, whether it be credit card information, passwords, or e-mail
addresses. It's not likely that it would happen, but browser developers
would be negligent if they allowed to be possible simply on the basis that
it's "not likely".
Accessing the local file system:

Well, reasons here should be obvious.
Accessing remote file systems:

This probably isn't a security issue, just that client-side JavaScript is
just that: client-side. There are very few reasons why a client-side
script should need to access something on the server. That's what
server-side languages are for.

There might be better examples, but this is what first entered my head.

Mike

--
Michael Winter
M.******@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[Nik Coughin]

Michael Winter wrote:

Security is privacy oriented. Possibilities.. .

Accessing HTML pages from other domains:

A script could interfere with a page. An extreme case might be one
that periodicly checks other pages for form fields that contain
personal information, whether it be credit card information,
passwords, or e-mail addresses. It's not likely that it would happen,
but browser developers would be negligent if they allowed to be
possible simply on the basis that it's "not likely".
Is that even possible? HTML pages don't store the content of form fields.
The browser does, and then sends that information to the server. There's no
way that allowing JS to have read access to a file on another domain --
which anyone with an Internet connection can access anyhow -- would allow
the fields of a form to be read.

Accessing the local file system:

Well, reasons here should be obvious.

Completely :)
There might be better examples, but this is what first entered my
head.

Thanks for taking the time to write Mike :) I guess what I'm trying to say
is, if a file is on the Internet and can be read by anyone with a browser,
then why can't my JavaScript read it?

[Michael Winter]

On Fri, 2 Apr 2004 10:01:56 +1200, Nik Coughin <nr***********@ woosh.co.nz>
wrote:

Michael Winter wrote:
[stealing data from another page]
Is that even possible? HTML pages don't store the content of form
fields. The browser does, and then sends that information to the
server. There's no way that allowing JS to have read access to a file
on another domain -- which anyone with an Internet connection can access
anyhow -- would allow the fields of a form to be read.
I was referring to an active page, in a frame, say. :)

A gateway site might load other pages into a frame, knowing full well that
a user might enter sensitive data into them. It could read it and send it
to a server for storage. The "Same Origin Policy" prevents that.

[snip]
I guess what I'm trying to say is, if a file is on the Internet and can
be read by anyone with a browser, then why can't my JavaScript read it?

As I said, client-side JavaScript is for performing actions on the client.
Very few browsers provide ways for scripts to communicate with remote
machines - server-side scripts should have provided them with all the
information they need.

I did forget to point out that there is an FAQ entry on this:

<URL:http://jibbering.com/faq/#FAQ4_38>

It does provide a solution that would work under some circumstances, but
if you were dependent on this approach, your page might be utterly useless
for unsupporting browsers.

Mike

--
Michael Winter
M.******@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[Nik Coughin]

Michael Winter wrote:

On Fri, 2 Apr 2004 10:01:56 +1200, Nik Coughin
<nr***********@ woosh.co.nz> wrote:

Michael Winter wrote: I was referring to an active page, in a frame, say. :)

A gateway site might load other pages into a frame, knowing full well
that a user might enter sensitive data into them. It could read it
and send it to a server for storage. The "Same Origin Policy"
prevents that.

Ahhh... gotcha :)
[snip]

I guess what I'm trying to say is, if a file is on the Internet and
can be read by anyone with a browser, then why can't my JavaScript
read it?

As I said, client-side JavaScript is for performing actions on the
client. Very few browsers provide ways for scripts to communicate
with remote machines - server-side scripts should have provided them
with all the information they need.

I did forget to point out that there is an FAQ entry on this:

<URL:http://jibbering.com/faq/#FAQ4_38>

It does provide a solution that would work under some circumstances,
but if you were dependent on this approach, your page might be
utterly useless for unsupporting browsers.

Mike

It's OK, I was just looking for a lazy way out to do something very simple
that is probably better done with PHP.

Thanks again!

[Jim Ley]

On Fri, 2 Apr 2004 10:01:56 +1200, "Nik Coughin"
<nr***********@ woosh.co.nz> wrote:

Michael Winter wrote:

Security is privacy oriented. Possibilities.. .

Accessing HTML pages from other domains:

A script could interfere with a page. An extreme case might be one
that periodicly checks other pages for form fields that contain
personal information, whether it be credit card information,
passwords, or e-mail addresses.

Most likely reason is to subvert IP based protection, if a certain
page is only accessible within the intranet, I just need to fool
someone to visit the page, then I can proxy myself through them.

Also if I can proxy myself through someone I can pretend to be them on
other sites, maybe sending spam, maybe ...

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/