"Placing the web site's data on a separate server is a good idea
because
you can keep the production server buried within the corporate security

layers (firewalls, etc.)."

Hmmm...

It was mandated that we do this when I was at HHH. I wanted to go for a
direct feed to/from the web from our central server but I was
overruled. What evolved was a "data transfer via encrypted email"
system to/from a web- and application- server (also running D3) hosted
at a remote site. It worked fine - although the need to get in the car
to go and administer the remote server was, to me at least, an
irritation. To be quite honest - I was never *really* happy with the
arrangement.

It makes sense from an ideal perspective to have the production D3
application server interacting with the wider world beyond the
firewalls. I'm thinking : serving up web pages, via FlashCONNECT say,
populated with "live" information and, optionally, generating "live"
orders - or whatever, always representing *real* *live*
*up-to-the-second* information. There then need be very little
difference, if any, between the pages accessed via the web and those
accessed by staff via a secure "log in". Your production systems,
historically using a green-screen UI, can be re-engineered to use a
browser UI and, where it makes sense to do so, made available to the
public via the web as a DIY option. The big question is : "Can it be
made safe?". Surely, if you're going to put up a web-site, you're going
to do all you can to ensure it's safe anyway.

Mike.

The OP didn't say what platform he has. Like I said in my other post,
if this is a traditional ADP (R&R does this similarly since he
mentioned auto dealer apps), the system is tighly locked down to
prevent any access to TCL or anything other than standard login.
Users of these systems have no access to any other account, no dm or
sysprog, nothing. The box is an application server with one way
in/out and the only people who can get in are ADP and R&R themselves.
They might even restrict q-pointer access via the upd/ret locking
mechanisms. Nasty way to do business IMO. All of these suggestions
for exporting data, FC, etc are nice but don't have anything to do
with the OP.

What bothers me is that the OP made a request and then disappeared.
Very bad form to ask for help and then not come back or simply not
respond.

T

Tony Gravagno <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote in
news:qqi6j19vd6d2s8tlmg0k7n1sf0e6raq8uj (AT) 4ax (DOT) com:

He may be reading in horror. Actually, Tony, you're pretty much
right on the money (as usual). I tried to circumvent these issues in my
previous post with my suggested solutions, but I'm not sure if anyone
picked up on them.

Being somewhat familiar with these systems, I can tell you that user
access is strictly limited to only what they need to run. In that sense,
they are good systems because they prevent users (and others) from
mucking about where they shouldn't be. Keeps things nice and tidy.

There are provisions for third party connectivity, but as I've already
tried to point out, things must be done "according to the rules" because
of the nature of the system. In all probability, the best way to extract
data is to hook into the web service and use the proprietary APIs to
obtain logical data sets (i.e., sales, inventory, repair orders,
invoices, customer profiles, etc.).

Regards,
Joe

Hi Mike,

And that is precisely what I was suggesting (and do regularly using
separate machines).

The choices aren't either direct exposure through a proprietary
protocol the OP may or may not even have or mule train (the bizzare
e-mail solution proposed).

As always there are many, many approaches. I suggested this one because
the OP said that he was familiar with php and mysql. If that is the
case (and barring the possibility that he hasn't control of his own
server as some have suggested) this would be a piece of cake for him.

Two machines can communicate through a solid tunnel and provide
immediate 'real, live, up-to-the-second' data representation. I can
give a hand if you need.

Ah, you are getting close to the point. In my experience, most
production servers run in a (ehem ...) relaxed security mode. This
includes shell accounts accessable through passwords (as opposed to
RSA), weak passwords, un-updated OS's (because RD or whomever won't
react fast enough to allow keeping up with security updates) and on and
on and on.

In these cases, exposing a mission critical machine containing valuable
and sensitive information to the Internet is not a good idea.
Especially when Apache is perfectly happy running on an old PII 350. So
cheap and easy, why would one wish to court disaster? Which security
hole will allow access to our payroll records? To our clients' credit
and credit card information?

Indeed but:
A dedicated web server is *MUCH* easier to properly secure than is the
typical production application-data-print-lunch server.

Part of making it as safe as possible is weighing the risks. Why would
you want sensitive information exposed when it has no use there anyway?
Bury the stuff that isn't needed on the web server, put the stuff that
*is* needed there and prosper.

These discussions always make me think of backup discussions. People
always start taking their backup plan seriously ... _after_ a crash and
no backup. Hope you don't have to learn the hard way.
-Tom

Tom deL wrote:
Hi Tom

I know I've drifted OT again but..

Let's say we have people accessing our green-screen application from a
remote site (a hotel room in another country or whatever) using a
terminal emulator. Let's say the application is nailed down as tight as
Tony describes - with update/retrieval locks and all the rest.

You wouldn't dream of hosting two distinct application servers, keeping
one for use in a strictly local private network and transferring only
selected data out to the separate server available to the chap in the
hotel room - would you?

I reckon that chap and others ought to be able to similarly access that
self-same application server running essentially the same, but
reengineered, software using their browser. If you have a secure web
site with a need to protect sensitive information - as millions
currently do - it shouldn't be any more of a problem to protect a pipe
from that secure web server to an application server beyond another
firewall, should it?

(Maybe I'm being naiive? I know I'm being lazy - I don't want to have
more servers to worry about than the minimum.)

All I would suggest there be on the secure web server is some software
to interact with the application server, and some gifs and stuff. No
sensitive data and no application software. I'm talking absolute
minimum, bare bones, ultra-thin web server. All of the real work goes
on on the application server. Let's assume that, although the web
server is as tight as tight can be, some nasty get's control of it.

What can said nasty do?

Mike.

Hi Mike,

And into a topic that is a bit too broad for this venue but:

You are taking a terribly narrow view of security. Update/Retrieval
locks are close to 100% meaningless to the kids who want to borrow (or
worse) your server. It is more likely than not that they have never
even heard of such devices. If they took the time to study them, they
would likely scoff at this 'security' and once they ownz your server
would just write something to extract the data from the raw filesystem
if they wished.

Your universe (pun intended) of D3 is nothing more than another
application to those folks and they would likely ignore it in favour of
something with which they are more familiar.

<SNIP>

Something tells me that you don't really want an answer from me on this
but here are a couple of hints:

Google around for cross site scripting (XSS) exploits. These favour
your 'secure' web UI's techniques and can be _very_ nasty. All that is
required is the leverage of a poorly written or configured script or an
(as yet unknown to you) bug in .net or php or java or ... and don't
forget that the 'nasties' have many, many ways to do things too.

For edification and entertainment you might build a honeypot on an old
junker PC. Understand the risks first, then study and learn from what
you see.

HTH,
-Tom

Hi, Rob Allen from ADP Dealer Services here. I still check this
newsgroup from time to time.

Joe and Tony have given the original poster the best advice so far.
Don't think of this as an ordinary Pick-based computer that the user
can add software to. We keep a really tight lid on things and most of
our clients like it that way.

Just to clarify, we currently sell IBM eServers running Red Hat Linux
and our own ancient version of Reality. We have some pretty nifty web
services now, so the original poster should definitely contact his ADP
support people.

Rob Allen
National Tech Support - Document Storage & Data Archiving team
ADP Dealer Services
Portland, OR

"Joe" <avoidingspam (AT) nospam (DOT) com> wrote

Not entirely correct. If you purchase user programming you have access to
tick as well as $. Now, granted, ADP follows none of the standard practices
with pretty much any *nix OS in terms of where things are and what is and is
not on the path but there are many low level items that can be accessed and
the DMS can be accessed via FTP to put/pull files (within the scope of ~/)
so the idea of polling and pulling information in a file within the user
home is feasible.

Important to note is user programming class is a requirement prior to
purchase of a user programming account

Rick

"Rick Cooper" <rick (AT) cooper-home (DOT) com> wrote in
news:Tl%if.3334$HC2.1323@trnddc06:

Considering the time and cost of:
a) Purchasing a user programming account
b) Attending user programming class
c) Figuring out how to construct logical data sets from raw DMS data

it would still probably be more cost effective to utilize third party
connectivity. In all likelihood, it's more expensive to reinvent the
wheel.

Regards,
Joe