But in this case we are doing centralized control by the host.  The 400
needs data from a PC in another state, at 2am in the morning.  Now I
suppose we could hire someone to come in at 2am and key the user id and
password.  Or we could hire someone to walk over to the PC in the remote
site and click on some silly icon - but there goes your centralized
control.  Yes, you are right we could write some sort of sockets thing or
whatever to do this, but we decided to do it this way.  It's our choice.
The password is not tacked up for everyone to find.  Anyone who has access
to the objects which have this buried can get to it but we assume that
people that have this kind of access are trusted employees.  After all,
sooner or later you have to be productive.  I am not interested in the
'cones of silence' from that old Get Smart movie.

In the case of the Domino (a different project) - we are running a stored

Rob Berendt

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin

                    "Joe Pluta"
                    <joepluta@PlutaBrot       To:     <midrange-l@midrange.com>
                    hers.com>                 cc:
                    Sent by:                  Fax to:
                    midrange-l-admin@mi       Subject:     RE: QUSER on ODBC 

                    12/14/2001 03:57 PM
                    Please respond to

> From: rob@dekko.com
> And how, pray tell, would you have a batch program, like RUNRMTCMD,
> your 400?  Force it to only run interactive and prompt the userid and
> password?

There are certainly many options, but one thing I probably would NOT do is
allow RUNRMTCMD.  Instead, I'd probably have a program that listened on a
specific port for a request.  The program would only allow requests from
certain trusted addresses.  This would all be on an internal
network (all with 10. addresses).

It would be a little more programming to add a new request, but that far
outweighs the security risks inherent with allowing unfettered access to
programs from a client.  Of course, you can attribute this whole discussion
to my view of distributed programming; I believe that centralized control
servers by the host is preferable to unbounded access by clients.


This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.