OSU server: upload script

Post by Phillip Helbig (undress to reply)
Does anyone have a basic DCL script which, when called as a script by
the web server, can upload a file from the browser machine to the server
machine?

CGI doesn't get used for this. A CGI-based fetch as you're likely
envisioning here would be routinely blocked network firewalls, among
other details.

What follows is a basic HTTP file upload discussion, one of many around
the 'net:

https://stackoverflow.com/questions/8659808/how-does-http-file-upload-work#8660740

Here's another related HTTP file upload discussion, with a live demo included:

https://www.w3schools.com/howto/howto_html_file_upload_button.asp

And somewhat more advanced, do not allow the user to provide a
filename, and do not allow execute access within the upload
directories. Particularly beware polyglot files; files an incautious
user might think harmless can be executables.

https://security.stackexchange.com/questions/116819/beside-gifar-are-there-any-other-known-polyglot-files

Open and insecure uploads can be quickly filled with warz and worse,
particularly if a remote user can then download the content.

--
Pure Personal Opinion | HoffmanLabs LLC

Arne Vajhøj

2020-10-20 19:11:34 UTC

Post by Phillip Helbig (undress to reply)
Does anyone have a basic DCL script which, when called as a script by
the web server, can upload a file from the browser machine to the server
machine?

CGI doesn't get used for this. A CGI-based fetch as you're likely
envisioning here would be routinely blocked network firewalls, among
other details.

????

I belive he is asking for:

browser---(POST of file)---web server---CGI script---disk file

That is very much possible. And the firewall will most likely not
even know that the target URL is a CGI script.

Post by Stephen Hoffman
And somewhat more advanced, do not allow the user to provide a filename,
and do not allow execute access within the upload directories.
Particularly beware polyglot files; files an incautious user might think
harmless can be executables.
https://security.stackexchange.com/questions/116819/beside-gifar-are-there-any-other-known-polyglot-files
Open and insecure uploads can be quickly filled with warz and worse,
particularly if a remote user can then download the content.

Yes - there are some security risks.

Uploading to a directory not served by the web server and use a download
script to get it may be a good thing.

Arne

Phillip Helbig (undress to reply)

2020-10-20 19:28:31 UTC

Post by Phillip Helbig (undress to reply)
Does anyone have a basic DCL script which, when called as a script by
the web server, can upload a file from the browser machine to the server
machine?

CGI doesn't get used for this. A CGI-based fetch as you're likely
envisioning here would be routinely blocked network firewalls, among
other details.

????
browser---(POST of file)---web server---CGI script---disk file

Right (I think).

Post by Arne Vajhøj
Uploading to a directory not served by the web server

Right.

Post by Arne Vajhøj
and use a download
script to get it may be a good thing.

Not sure what that means.

Arne Vajhøj

2020-10-20 19:38:38 UTC

Post by Phillip Helbig (undress to reply)
Does anyone have a basic DCL script which, when called as a script by
the web server, can upload a file from the browser machine to the server
machine?

CGI doesn't get used for this. A CGI-based fetch as you're likely
envisioning here would be routinely blocked network firewalls, among
other details.

????
browser---(POST of file)---web server---CGI script---disk file

Right (I think).

Post by Arne Vajhøj
Uploading to a directory not served by the web server

Right.

Post by Arne Vajhøj
and use a download
script to get it may be a good thing.

Not sure what that means.

If the web server serves DISK3:[WWW...] and you stuff uploads in
DISK3:[UPLOADS] then the web server cannot serve them and
you can make them available as /download.php?file=foobar
(or /htbin/download?file=foobar).

Arne

Dave Froble

2020-10-21 00:18:12 UTC

Post by Phillip Helbig (undress to reply)
Does anyone have a basic DCL script which, when called as a script by
the web server, can upload a file from the browser machine to the server
machine?

CGI doesn't get used for this. A CGI-based fetch as you're likely
envisioning here would be routinely blocked network firewalls, among
other details.

????
browser---(POST of file)---web server---CGI script---disk file

Right (I think).

Post by Arne Vajhøj
Uploading to a directory not served by the web server

Right.

Post by Arne Vajhøj
and use a download
script to get it may be a good thing.

Not sure what that means.

At the core of a web server is a "listener" which can implement
accepting incoming socket requests.

The "payload" can then be some standard action, or, a "script" to
execute can be part of the payload.

Web servers usually are set up to perform some standard actions, and
other actions will require a script for the desired action. These
scripts are what allows customization of a web server. If very specific
actions are required, that most likely will require a custom script.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Arne Vajhøj

2020-10-21 14:41:13 UTC

Post by Dave Froble
At the core of a web server is a "listener" which can implement
accepting incoming socket requests.
The "payload" can then be some standard action, or, a "script" to
execute can be part of the payload.
Web servers usually are set up to perform some standard actions, and
other actions will require a script for the desired action. These
scripts are what allows customization of a web server. If very specific
actions are required, that most likely will require a custom script.

More common terms today would be "static content" and "dynamic content".

Static content being HTML, CSS and JS.

Dynamic content being PHP, ASP.NET, Jave EE, RoR, node.js, CGI scripts etc..

Arne

Jan-Erik Söderholm

2020-10-21 15:27:29 UTC

At the core of a web server is a "listener" which can implement accepting
incoming socket requests.
The "payload" can then be some standard action, or, a "script" to execute
can be part of the payload.
Web servers usually are set up to perform some standard actions, and
other actions will require a script for the desired action. These
scripts are what allows customization of a web server. If very specific
actions are required, that most likely will require a custom script.

More common terms today would be "static content" and "dynamic content".
Static content being HTML, CSS and JS.
Dynamic content being PHP, ASP.NET, Jave EE, RoR, node.js, CGI scripts etc..
Arne

I would also count what is commonly called Ajax into the dynamic part.

I'm currently building a test mobile applications (POC) using
MIT App Inventor that first scans a product label (QR) and then
makes Ajax calls to our VMS system to fetch information for
display on the Android phone. Could be used on the factory floor
to quickly lookup the status of an item. A lot of fun and it
definitely makes “the old VAX” look better… 😊

https://appinventor.mit.edu/

Arne Vajhøj

2020-10-21 19:22:31 UTC

Post by Dave Froble
At the core of a web server is a "listener" which can implement
accepting incoming socket requests.
The "payload" can then be some standard action, or, a "script" to
execute can be part of the payload.
Web servers usually are set up to perform some standard actions, and
other actions will require a script for the desired action. These
scripts are what allows customization of a web server. If very
specific actions are required, that most likely will require a custom
script.

More common terms today would be "static content" and "dynamic content".
Static content being HTML, CSS and JS.
Dynamic content being PHP, ASP.NET, Jave EE, RoR, node.js, CGI scripts etc..

I would also count what is commonly called Ajax into the dynamic part.

Terminology can be difficult.

Seen from web server perspective a HTML5 bundle (HTML, CSS, JS) is
static content, because the web server basically just considers
them a bunch of bytes.

Seen from the user perspective it is dynamic content as it changes.

Post by Jan-Erik Söderholm
I'm currently building a test mobile applications (POC) using
MIT App Inventor that first scans a product label (QR) and then
makes Ajax calls to our VMS system to fetch information for
display on the Android phone. Could be used on the factory floor
to quickly lookup the status of an item. A lot of fun and it
definitely makes “the old VAX” look better… 😊

What do you use for the web services?

Arne

Jan-Erik Söderholm

2020-10-21 21:01:24 UTC

Post by Dave Froble
At the core of a web server is a "listener" which can implement
accepting incoming socket requests.
The "payload" can then be some standard action, or, a "script" to
execute can be part of the payload.
Web servers usually are set up to perform some standard actions, and
other actions will require a script for the desired action. These
scripts are what allows customization of a web server. If very
specific actions are required, that most likely will require a custom
script.

More common terms today would be "static content" and "dynamic content".
Static content being HTML, CSS and JS.
Dynamic content being PHP, ASP.NET, Jave EE, RoR, node.js, CGI scripts etc..

I would also count what is commonly called Ajax into the dynamic part.

Terminology can be difficult.
Seen from web server perspective a HTML5 bundle (HTML, CSS, JS) is
static content, because the web server basically just considers
them a bunch of bytes.
Seen from the user perspective it is dynamic content as it changes.

What do you use for the web services?
Arne

WASD as the web server frontend and PyRTE (Python Persistent Scripting)
with Python scripts as the backend. By using PyRTE there is no overhead
from the Python startup (which is usually 1-2 sec on our Alpha), the
scripts stays loaded and compiled within the PyRTE process and respons
times are done to 10s of ms. Well, you get the Python startup at first
access when the PyRTE process is created, it then lives for as long as
you have configured your idle time.

This works fine, we have built traditional web brower applications using
Javascript using the same backend.

https://wasd.vsm.com.au/wasd_root/src/python/READMORE.HTML

Arne Vajhøj

2020-10-21 23:37:19 UTC

What do you use for the web services?

WASD as the web server frontend and PyRTE (Python Persistent Scripting)
with Python scripts as the backend. By using PyRTE there is no overhead
from the Python startup (which is usually 1-2 sec on our Alpha), the
scripts stays loaded and compiled within the PyRTE process and respons
times are done to 10s of ms. Well, you get the Python startup at first
access when the PyRTE process is created, it then lives for as long as
you have configured your idle time.
This works fine, we have built traditional web brower applications using
Javascript using the same backend.
https://wasd.vsm.com.au/wasd_root/src/python/READMORE.HTML

Interesting. And definitely the way to go - CGI is rather costly
resource wise.

RPC style?
RESTful style?

Do you use a framework for the services like Flask?

Arne

Phillip Helbig (undress to reply)

2020-10-22 16:40:47 UTC

This might be too specific to the OSU-server, but maybe I can get some
feedback here.

If it's possible with some other programming language, it should be
possible with DCL, right? So if the answer to the first question is
"yes", then the answer to the second should be "yes" as well.

Here is an example page (which uses DCL_ENV_RM.COM which ships with the
OSU server):

<title>upload test</title>
<h1>upload test</h1>
<form method="POST" action="/scripts/dcl_env_rm">
Name:
<input name="name" type="text" size=40 maxlength=80><BR>
Comment:
<input type="text" name="textline" size="30"><BR>
file:
<input type="file" name="datafile" size="40">
<P>
<input type="submit" value="send">
</form>

It lets me choose a file on the system where the web browser is running
and the web server has the name of the file in WWW_FLD_DATAFILE.

What I need now is a procedure to replace DCL_ENV_RM.COM which would
copy the file specified in WWW_FLD_DATAFILE to a directory (could be
hard-coded) on the machine where the server is running. It would be
sufficient if it properly handles just normal text files (even just
7-bit printable ASCII would be enough).

Any ideas?

Many web sites allow one to browse a list of files on a local disk
accessible to the web browser and upload one or more, so this isn't
something really bizarre. My guess is that the OSU server would support
it. The question is whether it can be done without having to install
PHP or whatever. With regard to the scripting language, is there any
reason why DCL shouldn't work?

Arne Vajhøj

2020-10-22 17:33:07 UTC

Post by Phillip Helbig (undress to reply)
This might be too specific to the OSU-server, but maybe I can get some
feedback here.
If it's possible with some other programming language, it should be
possible with DCL, right?

Some things are a lot easier in other programming languages.

Post by Phillip Helbig (undress to reply)
Many web sites allow one to browse a list of files on a local disk
accessible to the web browser and upload one or more, so this isn't
something really bizarre.

True.

But they will be using a something suitable for the task like
PHP, Perl, ASP.NET C#, something Java, ASP classic VBS etc. not
a shell script like DCL.

Post by Phillip Helbig (undress to reply)
My guess is that the OSU server would support
it. The question is whether it can be done without having to install
PHP or whatever. With regard to the scripting language, is there any
reason why DCL shouldn't work?

Take a look at CGILIB.C and SCRIPTLIB.C and see if you could do that
in DCL.

Maybe you can. But lots of work.

Arne

Simon Clubley

2020-10-22 17:43:46 UTC

Post by Phillip Helbig (undress to reply)
What I need now is a procedure to replace DCL_ENV_RM.COM which would
copy the file specified in WWW_FLD_DATAFILE to a directory (could be
hard-coded) on the machine where the server is running. It would be
sufficient if it properly handles just normal text files (even just
7-bit printable ASCII would be enough).
Any ideas?
Many web sites allow one to browse a list of files on a local disk
accessible to the web browser and upload one or more, so this isn't
something really bizarre. My guess is that the OSU server would support
it. The question is whether it can be done without having to install
PHP or whatever. With regard to the scripting language, is there any
reason why DCL shouldn't work?

DCL will need access to the POST data, which is where you can find the
contents of the file.

Since I have never been insane enough to directly connect DCL to a
public facing URL, I have never done this so I don't know what
information is made available to the command procedure or how much
manual processing of the POST data you would need to do within DCL.

Just use PHP or another scripting language. On other operating systems,
these scripting languages have full support for this and present the file
data and other POST data in an easy to access format within your script.

If you continue with DCL, read this before continuing:

https://en.wikipedia.org/wiki/Code_injection#Shell_injection

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Jan-Erik Söderholm

2020-10-22 21:04:33 UTC

DCL will need access to the POST data, which is where you can find the
contents of the file.
Since I have never been insane enough to directly connect DCL to a
public facing URL...

I cannot remember any talks about any "public facing URL" here.

Post by Simon Clubley
I have never done this so I don't know what
information is made available to the command procedure...

As far as I remember from OSU (it must have been 15-20 years since
I switch to the much more capable and up-to-date WASD) there is a
DCL-CGI interface so the OSU server sets up some symbols for you
that helps.

WASD has similar processing help, of course. And probably with more
functionallity.

Post by Simon Clubley
or how much
manual processing of the POST data you would need to do within DCL.
Just use PHP or another scripting language. On other operating systems,
these scripting languages have full support for this and present the file
data and other POST data in an easy to access format within your script.
https://en.wikipedia.org/wiki/Code_injection#Shell_injection
Simon.

Simon Clubley

2020-10-23 12:24:43 UTC

DCL will need access to the POST data, which is where you can find the
contents of the file.
Since I have never been insane enough to directly connect DCL to a
public facing URL...

I cannot remember any talks about any "public facing URL" here.

Webservers are usually used in a public facing way and which is how
I used them on VMS.

However, the last time I ran a webserver on VMS was 15 years ago and
even then I was skittish about doing that.

I also thought that Phillip was presenting various services on his
cluster to the outside world, at least that's what he has implied
with various questions he has asked here.

Post by Simon Clubley
I have never done this so I don't know what
information is made available to the command procedure...

As far as I remember from OSU (it must have been 15-20 years since
I switch to the much more capable and up-to-date WASD) there is a
DCL-CGI interface so the OSU server sets up some symbols for you
that helps.
WASD has similar processing help, of course. And probably with more
functionallity.

Does it write the file data to a temporary file ? DCL symbols are
not capable of holding the contents of a file unless it's extremely
small.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Jan-Erik Söderholm

2020-10-23 13:30:59 UTC

DCL will need access to the POST data, which is where you can find the
contents of the file.
Since I have never been insane enough to directly connect DCL to a
public facing URL...

I cannot remember any talks about any "public facing URL" here.

Can sometimes be a bad idea. :-)

But even so, it is not hard to make a public web interface to
a VMS box secure. It is not like letting everyone have an open
interface to DCL.

Post by Simon Clubley
...that Phillip was presenting various services on his
cluster to the outside world, at least that's what he has implied
with various questions he has asked here.

Post by Simon Clubley
I have never done this so I don't know what
information is made available to the command procedure...

As far as I remember from OSU (it must have been 15-20 years since
I switch to the much more capable and up-to-date WASD) there is a
DCL-CGI interface so the OSU server sets up some symbols for you
that helps.
WASD has similar processing help, of course. And probably with more
functionallity.

Does it write the file data to a temporary file ? DCL symbols are
not capable of holding the contents of a file unless it's extremely
small.
Simon.

I never said that there was a DCL method to upload files. I have no
idea. But there is a generic CGI interface to DCL. I could look it up
but so can anyone.

Phillip Helbig (undress to reply)

2020-10-23 14:07:48 UTC

Post by Jan-Erik Söderholm
But even so, it is not hard to make a public web interface to
a VMS box secure. It is not like letting everyone have an open
interface to DCL.

Right. Run the server on an account with no privileges and, if you
wish, have password-protected pages. These can use the SYSUAF and
produce VMS intrusions in case of problems, which you can tailor to
taste. Let it use a disk used by nothing else. Adjust process priority
and quotas. Run HTTPs if you wish.

Arne Vajhøj

2020-10-24 00:41:36 UTC

Post by Jan-Erik Söderholm
But even so, it is not hard to make a public web interface to
a VMS box secure. It is not like letting everyone have an open
interface to DCL.

If you allow any type of upload and you are not careful, then
you can still get into big problems with a no priv setup.

Arne

Phillip Helbig (undress to reply)

2020-10-24 03:31:03 UTC

Post by Jan-Erik Söderholm
But even so, it is not hard to make a public web interface to
a VMS box secure. It is not like letting everyone have an open
interface to DCL.

If you allow any type of upload and you are not careful, then
you can still get into big problems with a no priv setup.

Consider the setup described above: to do an upload, I need an account
on the system, and guessing the password wrongly will create intrusions.
Once I'm logged in, I can upload something, but at worst I can fill up a
disk used by nothing else. The uploaded file lands on a disk not
visible to the web server.

Arne Vajhøj

2020-10-24 23:49:08 UTC

Post by Jan-Erik Söderholm
But even so, it is not hard to make a public web interface to
a VMS box secure. It is not like letting everyone have an open
interface to DCL.

If you allow any type of upload and you are not careful, then
you can still get into big problems with a no priv setup.

If the non priviliged server account has write access to
the content, then you need to prevent content from
being modified.

Post by Phillip Helbig (undress to reply)
The uploaded file lands on a disk not
visible to the web server.

Which helps with security..

Arne

Arne Vajhøj

2020-10-24 00:37:37 UTC

Post by Simon Clubley
Since I have never been insane enough to directly connect DCL to a
public facing URL...

I cannot remember any talks about any "public facing URL" here.

Webservers are usually used in a public facing way and which is how
I used them on VMS.
However, the last time I ran a webserver on VMS was 15 years ago and
even then I was skittish about doing that.

Depends a bit on what "public" means.

A very common meaning is "visible to public internet".

And there are lots of web servers not available on the internet.

And I would expect the vast majority of VMS web servers to not be
available on the internet.

If you just mean visible outside the data center / server room,
then it is probably most web servers.

Post by Simon Clubley
I have never done this so I don't know what
information is made available to the command procedure...

As far as I remember from OSU (it must have been 15-20 years since
I switch to the much more capable and up-to-date WASD) there is a
DCL-CGI interface so the OSU server sets up some symbols for you
that helps.
WASD has similar processing help, of course. And probably with more
functionallity.

Does it write the file data to a temporary file ? DCL symbols are
not capable of holding the contents of a file unless it's extremely
small.

That wa smy concern as well.

But it turned out that CGI_SYMBOLS indeed has a capability to write
body to file.

Arne

Phillip Helbig (undress to reply)

2020-10-24 03:25:55 UTC

Post by Jan-Erik Söderholm
I cannot remember any talks about any "public facing URL" here.

Webservers are usually used in a public facing way and which is how
I used them on VMS.
However, the last time I ran a webserver on VMS was 15 years ago and
even then I was skittish about doing that.

Depends a bit on what "public" means.
A very common meaning is "visible to public internet".
And there are lots of web servers not available on the internet.

Right.

Post by Arne Vajhøj
And I would expect the vast majority of VMS web servers to not be
available on the internet.

Right.

Post by Arne Vajhøj
If you just mean visible outside the data center / server room,
then it is probably most web servers.

Right.

It's not uncommon to have an internal network for backend machines,
which are perhaps all in the same data centre(s); and then a network
internal to the company for users of those machines (as opposed to the
technical people running them), but completely isolated from the
internet; machines visible to the internet might be completely isolated
from both networks above.

Post by Jan-Erik Söderholm
As far as I remember from OSU (it must have been 15-20 years since
I switch to the much more capable and up-to-date WASD) there is a
DCL-CGI interface so the OSU server sets up some symbols for you
that helps.
WASD has similar processing help, of course. And probably with more
functionallity.

Does it write the file data to a temporary file ? DCL symbols are
not capable of holding the contents of a file unless it's extremely
small.

That wa smy concern as well.
But it turned out that CGI_SYMBOLS indeed has a capability to write
body to file.

Yes, thanks to Arne I now have a working example.

Phillip Helbig (undress to reply)

2020-10-23 14:04:27 UTC

Post by Jan-Erik Söderholm
I cannot remember any talks about any "public facing URL" here.

Webservers are usually used in a public facing way and which is how
I used them on VMS.

They are also often used on internal networks. Many things which used
FMS or DECForms or whatever in the past are often written today with a
webserver presenting some form as a gui and accessed via a web browser.
Of course, being on private networks, these aren't publicly visible.

Post by Simon Clubley
I also thought that Phillip was presenting various services on his
cluster to the outside world, at least that's what he has implied
with various questions he has asked here.

I wear many hats. :-)

Simon Clubley

2020-10-23 17:15:50 UTC

Post by Phillip Helbig (undress to reply)
Of course, being on private networks, these aren't publicly visible.

Are you sure ? :-)

For example, at one time, network printers were merely devices for
printing on sheets of paper.

Now they can also be used to compromise the rest of the network.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Phillip Helbig (undress to reply)

2020-10-23 17:51:08 UTC

Post by Phillip Helbig (undress to reply)
Of course, being on private networks, these aren't publicly visible.

Are you sure ? :-)
For example, at one time, network printers were merely devices for
printing on sheets of paper.
Now they can also be used to compromise the rest of the network.

I mean something on a network 192.168.1.*. You can't connect to that IP
address from the outside world unless some gateway is involved, and you
have control over where requests from outside go to. As an example,
they could all go to one machine, or some cluster address, but other
machines on the network aren't visible from outside. Sure, if you get
inside the door, then you can go into another room, but that is a common
problem and has nothing to do with VMS.

Scott Dorsey

2020-10-23 22:50:53 UTC

Post by Phillip Helbig (undress to reply)
Of course, being on private networks, these aren't publicly visible.

Are you sure ? :-)
For example, at one time, network printers were merely devices for
printing on sheets of paper.
Now they can also be used to compromise the rest of the network.

I think he is pointing out that since it is increasingly easier for people
to get inside the door thanks to devices like network printers which can be
turned into devices that open outgoing connections to servers that feed them
commands to do evil, that many people are no longer willing to consider their
internal network to be the isolated garden that they once did.

And no, that problem has nothing to do with VMS, but it means that you need
to either prepare VMS systems as if they were on external networks even when
they are not, or make that much more effort to keep isolated networks isolated
even in the face of misguided employees who plug wifi-enabled printers into
them which might inadvertently gateway wifi devices to the internal net.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Arne Vajhøj

2020-10-24 00:32:44 UTC

Post by Scott Dorsey

Post by Phillip Helbig (undress to reply)
Of course, being on private networks, these aren't publicly visible.

Are you sure ? :-)
For example, at one time, network printers were merely devices for
printing on sheets of paper.
Now they can also be used to compromise the rest of the network.

I think he is pointing out that since it is increasingly easier for people
to get inside the door thanks to devices like network printers which can be
turned into devices that open outgoing connections to servers that feed them
commands to do evil, that many people are no longer willing to consider their
internal network to be the isolated garden that they once did.
And no, that problem has nothing to do with VMS, but it means that you need
to either prepare VMS systems as if they were on external networks even when
they are not, or make that much more effort to keep isolated networks isolated
even in the face of misguided employees who plug wifi-enabled printers into
them which might inadvertently gateway wifi devices to the internal net.

There should be a firewall between PC & printer LAN and the servers.

Arne

Scott Dorsey

2020-10-24 12:40:36 UTC

Post by Arne Vajhøj
There should be a firewall between PC & printer LAN and the servers.

This is also true, but seldom implemented, and often out of control of
the server admins. Although you do of course need a hole in the wall so
you can print from the servers.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Jan-Erik Söderholm

2020-10-24 14:38:27 UTC

Post by Scott Dorsey

Post by Arne Vajhøj
There should be a firewall between PC & printer LAN and the servers.

This is also true, but seldom implemented, and often out of control of
the server admins. Although you do of course need a hole in the wall so
you can print from the servers.
--scott

I think some remote/web printing solutions works by opening a port
against some server (that is done by the printer itself when you
enable that function within the printer) and printouts can then be
sent from the outside over that link.

So you do not need to open up anything in your router/firewall,
it is done automatically using standard protocols by the printer.

Now, I have no idea if this is a security issue, I guess it is
very much donw to the actual implementation. Note also that all
accesses to the printer is done over that remote "printer server"
that is usually run by the printer manufacturer such as HP.

Anyone doing a printout has to connect to that server first and I do
not think that the open port can be accessed from some other source.

Phillip Helbig (undress to reply)

2020-10-22 16:51:41 UTC

Post by Phillip Helbig (undress to reply)
<title>upload test</title>
<h1>upload test</h1>
<form method="POST" action="/scripts/dcl_env_rm">
<input name="name" type="text" size=40 maxlength=80><BR>
<input type="text" name="textline" size="30"><BR>
<input type="file" name="datafile" size="40">
<P>
<input type="submit" value="send">
</form>

Maybe I need

enctype="multipart/form-data"

as well, but then the FORM_ symbols are not correct, or at least I don't
understand them.

Jean-François Piéronne

2020-10-22 06:16:20 UTC

Le 21/10/2020 à 23:01, Jan-Erik Söderholm a écrit :
{snip]

Post by Jan-Erik Söderholm
WASD as the web server frontend and PyRTE (Python Persistent Scripting)
with Python scripts as the backend. By using PyRTE there is no overhead
from the Python startup (which is usually 1-2 sec on our Alpha), the
scripts stays loaded and compiled within the PyRTE process and respons
times are done to 10s of ms. Well, you get the Python startup at first
access when the PyRTE process is created, it then lives for as long as
you have configured your idle time.

Mark has updated the PyRTE for Python 3.10,
https://wasd.vsm.com.au/py-bin/pyrte_test2.py

https://wasd.vsm.com.au/py3-bin/pyrte_test2.py

Python 3.10 startups is also much faster than 2.7

Example, on one system:
Python2 startup is 1.6s
Python3 startup is 0.3

Post by Jan-Erik Söderholm
This works fine, we have built traditional web brower applications using
Javascript using the same backend.
https://wasd.vsm.com.au/wasd_root/src/python/READMORE.HTML

I have also developed, requested by some customer, a CGIPlus interface
to RabbitMQ, a simple test Client -> WASD -> RabbitMQ -> APPserver
sustains thousand requests/s

The interesting part is that the appserver can be written in any
language on any system.

I have provided Python, C, Cobol examples.

One of Python example query the famous personnel database.

JF

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

Stephen Hoffman

2020-10-20 19:37:13 UTC

Post by Phillip Helbig (undress to reply)
Does anyone have a basic DCL script which, when called as a script by
the web server, can upload a file from the browser machine to the server
machine?

CGI doesn't get used for this. A CGI-based fetch as you're likely
envisioning here would be routinely blocked network firewalls, among
other details.

????
browser---(POST of file)---web server---CGI script---disk file
That is very much possible.

Note that I did not state that scripting an upload was impossible, and
please see previously-linked resources around using POST for secure
file uploads.

Post by Arne Vajhøj
And the firewall will most likely not even know that the target URL is
a CGI script.

And I'm here assuming that this was for "sort of the equivalent of
anonymous FTP" and a "basic DCL script" for the upload, hence my links
to using POST.

If the DCL script is running an FTP CGI as was suggested, it'll both be
insecure, and it'll be blocked by firewalls on all but wide-open
networks.

And absent webserver extensions or local support for it, DCL is just
bad dealing with POST data, having run afoul of that (lack of) support
before.

--
Pure Personal Opinion | HoffmanLabs LLC

Arne Vajhøj

2020-10-20 19:46:22 UTC

Post by Phillip Helbig (undress to reply)
Does anyone have a basic DCL script which, when called as a script
by the web server, can upload a file from the browser machine to the
server
machine?

CGI doesn't get used for this. A CGI-based fetch as you're likely
envisioning here would be routinely blocked network firewalls, among
other details.

????
browser---(POST of file)---web server---CGI script---disk file
That is very much possible.

Note that I did not state that scripting an upload was impossible,

What I outlined above is not scripting an upload.

Scripting an upload would be:

script---browser---(POST of file)---web server---?---disk file

Post by Stephen Hoffman
and
please see previously-linked resources around using POST for secure file
uploads.

There are only two options for file upload: POST and PUT.

Post by Arne Vajhøj
And the firewall will most likely not even know that the target URL is
a CGI script.

And I'm here assuming that this was for "sort of the equivalent of
anonymous FTP" and a "basic DCL script" for the upload, hence my links
to using POST.

It was the service that would be similar to a FTP service.

Post by Stephen Hoffman
If the DCL script is running an FTP CGI as was suggested,

What is an FTP CGI?

Arne

Stephen Hoffman

2020-10-20 19:56:46 UTC

Post by Arne Vajhøj
What is an FTP CGI?

$! MY_FTP_CGI.COM
$ COPY /FTP here there

--
Pure Personal Opinion | HoffmanLabs LLC

Arne Vajhøj

2020-10-20 20:03:16 UTC

Post by Arne Vajhøj
What is an FTP CGI?

$! MY_FTP_CGI.COM
$ COPY /FTP here there

Ah.

browser---web server---CGI script---FTP server---files

Arne

Simon Clubley

2020-10-21 12:10:45 UTC

Post by Arne Vajhøj
What is an FTP CGI?

$! MY_FTP_CGI.COM
$ COPY /FTP here there

I hope someone does a lot of validation before using that from DCL
with untrusted input. :-)

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Dave Froble

2020-10-21 00:12:24 UTC

Post by Phillip Helbig (undress to reply)
The OSU list is rather quiet, so I'll ask here as well.
So far, I've done only one-way traffic with my webserver. However, I
would like to experiment with the possibility of uploading stuff to it,
sort of the equivalent of anonymous FTP. I just want to get the hang of
it, so a simple working example would be nice---then I know that if it
doesn't work, then there is some other problem and not the script
itself.
Does anyone have a basic DCL script which, when called as a script by
the web server, can upload a file from the browser machine to the server
machine?

I haven't done this, but, I'd guess an HTTP PUT from the client might be
a method. The web server would have to have scripts to implement doing
something with any incoming data.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

BlackCat

2020-10-21 12:29:46 UTC

Post by Phillip Helbig (undress to reply)
The OSU list is rather quiet, so I'll ask here as well.
Does anyone have a basic DCL script which, when called as a script by
the web server, can upload a file from the browser machine to the server
machine?

Do you mean something like WebDAV - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) see RFC5689.
Available with WASD and/or CSWS (Apache) for OpenVMS.

I would go with WASD any day. ;-)

seasoned_geek

2020-10-23 20:42:30 UTC