FP Web

Mike Dawson mikedawson at bellsouth.net
Mon Jul 8 09:23:21 PDT 2019 

Folks, it's been a very long time......probably not long enough for some...but
For what it's worth....... "a very long time ago in a galaxy far far away...."

Fairlite's OneGate enabled me to do the following (in a *NIX env):

1.  A complete filePro web (CGI based),  secure (as secure as CGI can be), app/system. 
2.  A complete MySQL server interface,  running parallel to fP.  (Think:  NEWREC, UPDATE, ADDREC with specific keys and SQL scripting via the USER cmd real time).
	(Yes it worked flawlessly and was extremely fast.  The fP tables were the master set.)
3.  A complete fP based "screen scraper" for HTML use.  IE:  Define screens that were called via OneGate processing tables dynamically,  using specific field preface delimiters to instruct RREPORT how to process.
	( I found that about 4 variants of the preface meta characters were all you need to write some really intense dynamic fP web apps).  IE dropdowns, dynamic links, input fields etc.
4.  Dynamic JavaScript generated from fP on the fly.
5.  End to End AJAX processing.
6.  SOAP/XML services back to fP data utilizing PHP/SOAP custom API's.

My point is this.......  if you are a developer who understands the depth of what I just described and the toolset required to make it all work harmoniously, then you are a developer who
also knows there are better ways to get your data on the web with a intelligent UI/UX.

That being said, I don't care what is presented,  you WILL need these toolsets to compete in today's MVC/SQL world with a fP backend.  You WILL need to completely understand
how the systems are supposed to work.   Period.    

One of the main reasons fP was so successful.... (please jump in the way back when machine as I can't remember) was the ability to upsell, and control AI content.  In other words,  "*CABE".
In today's world you have kids being taught Python, SQL, JavaScript, HTML, etc in the third grade.  I moved on to Python long ago, and am actually compiling it for distribution purposes.  BOOM!
I wish fP sales the absolute best of luck, but unless you've created an API that does all of the work I mentioned above, your only market share will be the entrenched die hard customer with dreams
of making ALL their original .PRC's run real time on the web......without changing a lick of source........    Arghhh....  GLWT.     

"We must embrace the change we wish to become..."

Thanks for listening.....and all the best!

<MD>

P.S.  OneGate is a fabulous robust product.  I can only imagine what it's capable of today......it is however....only part of the equation, just as anything else
	fP is getting ready to market.   "Just Say'n"
 

-------------
-----Original Message-----
From: Filepro-list [mailto:filepro-list-bounces+mikedawson=bellsouth.net at lists.celestial.com] On Behalf Of Richard Kreiss via Filepro-list
Sent: Monday, July 08, 2019 11:38 AM
To: Jose Lerebours; 'filepro-list at lists.celestial.com'
Subject: RE: FP Web

I am just now wondering if the FP Web is tied into MySQL download? Or is it a new front end for filePro replacing the FPGUI product?

It would be nice if there were some screen shots of the product on the FP TECH web-site (and a place to register for the conference).

Richard Kreiss
GCC Consulting

-----Original Message-----
From: Filepro-list <filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com> On Behalf Of Jose Lerebours via Filepro-list
Sent: Monday, July 8, 2019 6:14 AM
To: filepro-list at lists.celestial.com
Subject: Re: FP Web


On 7/8/19 12:30 AM, Fairlight via Filepro-list wrote:
>> Per injections, well, that has nothing to do with the back-end 
>> binaries but with the way the programmer writes his/her code.  Of 
>> course, if fileProWeb does not provide means to sanitize data, we 
>> then have a totally different subject.
> Not actually true, in the case of fpcgi 1.x and the default for 2.x.
> The whole concept of putting the command-lines as hidden fields was 
> ill-conceived, to put it as politely as possible.  Even after they 
> were made aware of the ramifications, they only provided an 
> alternative server-side only methodology for 2.x, but kept the 
> client-side methodology as the default.  Allegedly for purposes of 
> backwards compatibility.  I don't even think the alternative was 
> widely communicated.  So yes, injections -were- an issue with fpcgi, 
> just not in the conventional SQL injection context.  Worse, honestly, 
> since you could inject entire arbitrary commands.  It was an issue 
> even on Windows.  There were also multiple different characters to use 
> to trigger it.  They eventually fixed it, but that was -not- a good demonstration of security awareness.
>
> Then there was the makedir suid root hidden-password bypass at a 
> system level, if you had any system shell access and could access the 
> path to the binary.  Don't start me.

The way I see it,

(1) if "system" commands are needed to get to the data, then it is not a "native" solution; I stick to what I already know and works.
(2) It needs to have ability to run cURL and WSDL construct for data sharing (IN/OUT)
(3) It needs to have ability to use input in GET and POST modes

Being an old school developer, I can live with procedural architecture but OOP is where it should be.  I want to believe that they have hacked an open source binary like PHP, Perl or Python and made it their own, one where your typical filePro commands work:

lookup alias = fileName i=A k="Hello World!"

This would be the equivalent of a SQL query

SELECT * FROM fileName WHERE keyField = "HelloWorld!"

Then I can proceed to parse through the array object returned by the lookup/SELECT command without having to break out to a shell using "system".



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20190708/eff573e9/attachment.html>
_______________________________________________
Filepro-list mailing list
Filepro-list at lists.celestial.com
Subscribe/Unsubscribe/Subscription Changes
http://mailman.celestial.com/mailman/listinfo/filepro-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 13163 bytes
Desc: not available
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20190708/06537b97/attachment.bin>
_______________________________________________
Filepro-list mailing list
Filepro-list at lists.celestial.com
Subscribe/Unsubscribe/Subscription Changes
http://mailman.celestial.com/mailman/listinfo/filepro-list

More information about the Filepro-list mailing list