× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



The reason you can't directly run a job that takes over one minute is
that brewers have built in timeouts; IE uses 2 minutes (IIRC). You
certainly can run a job that takes longer; but you can't have the
browser wait. You end up writing code to "submit" a job and keep
refreshing (automatically) a page to see if it is done; or provide some
sort of asynchronous message (i.e. e-mail). The wording was bad on my
part; certainly it can be done - but the implementation can be
non-trivial.

How do you use the native model? - I suppose you could switch users on
the webserver; but I think that would get pretty messy. I don't think I
have ever seen a web application that does this; most use a single
account with near god-like powers to access machine/database resources
as the webserver and rely solely on application implemented permission
sets to define what the user can and cannot do. 

Of course you are correct - SQL injection vulnerabilities are caused by
poor input validation; web (or any others) applications should not have
this problem. Web design; however often contributes to the problem - I
can't tell you how many times I have heard "its in a list box - the user
cannot change it". Platform does make a difference; strong data typing
is very helpful in preventing this (and other) attacks. Additionally,
platform does also make a difference in the built in tools for data
validation.

The overflow option is a new one to me - I'll be using that.

Also; slowness is definably an issue - it takes a good deal more
hardware to push a web interface than 5250 esp. if you are going to do
SSL; additionally web pages generally have a lot more data associated
with them than telnet - as several others have noted. 

All in all I think that the message here is not that a browser based app
is a bad choice; but that there are positives and negatives; they need
to be weighed against your requirements.



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Thursday, December 30, 2004 11:11 AM
To: Midrange Systems Technical Discussion
Subject: RE: Why NOT the web?

/snip

Jay mentioned things you can't do in a browser. I disagree. As for
column headers, since you can't have more than 24 lines on a screen in
5250, simply implement the same limit on the web and use Prev and Next
buttons. However, if you want to take advantage of what the web offers
then you can have fixed headers. Want to see scrolling with fixed column
headers? Look at http://w3.techsoftwareinc.com/scroll.htm  I'm not sure
what you mean by manipulate w/o rerunning select, so I'll leave that
alone. As for validating input w/o refreshing interface, sure you can --
Look at hidden windows or IFRAMES. Why can't you run a job that takes >
1 minute? If you don't want to roll your own, use the native model, it
works fine. I'd like to know why SQL injection "will be a problem" on
the web. A well designed app is immune to SQL injection. However, a
poorly designed one isn't. SQL Injection isn't a function of the choice
of platform, it's a function of the quality of code.




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-2024 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.