Paradox Community

Items in pnews.paradox-programming

Subject:Re: Sessions
Date:Tue, 26 Sep 2023 10:35:24 -0700
From:Peter <peterspammenot@whiteknight.email>
Newsgroups:pnews.paradox-programming
I appreciate the time you took Tom, for your comments. I am aware of the 
impending fate of Paradox and its limitations and so are my customers. 
Paradox is all I know and I am too old to learn something else. This 
community is invaluable to me in order to keep going with Paradox and I 
appreciate everyone's comments/help.

That server idea sounds really cool but unfortunately the community 
stuff is no longer available so that's out - not sure if I could 
implement it anyways but could be fun to try. My security system is not 
about protecting tables (I got that message long ago), it is only about 
limiting users access to/in forms and other features that they do not 
have rights to.

On the personal side, I've given up on Windows and switched to Linux. 
Obviously big limitations but Windows just isn't for me anymore so I 
make due.

Peter


On 09/26/2023 12:17 a.m., Tom Krieg wrote:
> I solved the problem of insecure Paradox tables and useless passwords by 
> having the tables on a secure server to which users had no access. The 
> Corel web server OCX ran on this server and listened for  requests. It 
> would pass these requests to a Paradox library and the library would 
> handle them all, including receiving tables (e.g a tableframe) and 
> returning a table (e.g a query).
> 
> The Paradox client would send a request for data or to do something, the 
> server would send a resultstring, OK for an update, insert or delete or 
> a csv string to be turned into a result table.
> 
> Users would log in (send it to the server) the server would validate the 
> user.
> User name, password and all rights to the application would be 
> encrypted. This included which forms a user could open.
> 
> No one ever had access to the tables except the server. Users could open 
> local forms or scripts but without valid sever credentials, the form etc 
> would not open.
> 
> This scenario required
> - Tony McGuire's HTTP control, used by Paradox to send HTTP requests and
>      manage HTTP responses
> - The Corel Web Server OCX, to handle HTTP requests and return HTTP
>      responses
> - Tony McGuire's encryption control, to encrypt user credentials
> - Some out-of-the-box thinking
> 
> Unless you can find these controls and work out how to use them, give up.
> 
> I developed a Paradox application for a real estate company in Vermont 
> back in 2002 where the agents were on the road and the server was at 
> headquarters. Worked well.
> 
> I initially developed  the above Paradox application for an Australian 
> autoparts importer and wholesaler with 3 branches thousands of miles 
> apart. 256Mbit DSL line and all 3 branches used the one database. No 
> security or password issues.
> 
> Of course, when I converted everything to PotgreSQL running on a server, 
> this became obsolete. It was also easy to do because all I had to do was 
> replace the Paradox table libraries with PostgreSQL libraries. In fact, 
> I ran a hybrid system for 6 months, replacing libraries one at a time 
> without users even being aware (except whenever a new library came on 
> stream, the response time would improve).
> 
> The next version of Windows 11 (23H2) will kill Paradox, from what I've 
> read so I wouldn't waste my time. Windows10 has just over a year to live 
> unless you  want to run it in a cave without users.
> 
> On 22/09/2023 6:17 am, Peter wrote:
>> Whenever adding passwords I have always used
>> var ses  session endvar
>> ses.open()
>> ses.addPassword()
>>
>> I got that from some help example and now I am wondering why a session 
>> needs to be opened.
>>
>> More thinking
>> I open a form and add necessary passwords to access tables
>>
>> I run a method and add password(s), then when the method finishes I 
>> remove all passwords.
>>
>> If I remover all passwords now the form is affected; true?
>>
>> It would seem to me that if running a separate method requires its own 
>> passwords then that is when I should add a session so I do not affect 
>> other passwords already established.
>>
>> Do I have this right?


Copyright © 2004 thedbcommunity.com