web app and application persistency

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

web app and application persistency

Felipe Monteiro de Carvalho
Hello,

This is kind of a theorical question, but I though I'd ask before
starting to code =)

Basically I have a desktop app which I need to retrofit into a
web-app. My idea is to cut it in a visual and a non-visual part and
implement the visual part in HTML+JavaScript and keep the non-visual
like it is now, in Pascal.

So, the problem is that CGI apps are started for every request, correct?

So how should I proceed to obtain a application which will keep
running for the entire session of a user? I don't want to simply save
session info because the application is rather large, there are lots
of things going on and it would be much easier for my coding if I
could keep the program running on the web server ...

Any ideas?

thanks,
--
Felipe Monteiro de Carvalho
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Michael Van Canneyt


On Mon, 1 Aug 2011, Felipe Monteiro de Carvalho wrote:

> Hello,
>
> This is kind of a theorical question, but I though I'd ask before
> starting to code =)
>
> Basically I have a desktop app which I need to retrofit into a
> web-app. My idea is to cut it in a visual and a non-visual part and
> implement the visual part in HTML+JavaScript and keep the non-visual
> like it is now, in Pascal.
>
> So, the problem is that CGI apps are started for every request, correct?

Correct.

There are techniques to avoid this: fastcgi, apache module, embedded server.

>
> So how should I proceed to obtain a application which will keep
> running for the entire session of a user? I don't want to simply save
> session info because the application is rather large, there are lots
> of things going on and it would be much easier for my coding if I
> could keep the program running on the web server ...
>
> Any ideas?

If you really want the application running 100% of the time, there are only 2 options:
- fastcgi with mod_fastcgi (NOT mod_fcgid) and ExternalFastCGIServer option.
- Embedded server (i;e. the application acts as a webserver).

Both ways are supported with fpWeb. I use fastcgi.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Marcos Douglas B. Santos
In reply to this post by Felipe Monteiro de Carvalho
On Mon, Aug 1, 2011 at 11:21 AM, Felipe Monteiro de Carvalho
<[hidden email]> wrote:

>
> Hello,
>
> This is kind of a theorical question, but I though I'd ask before
> starting to code =)
>
> Basically I have a desktop app which I need to retrofit into a
> web-app. My idea is to cut it in a visual and a non-visual part and
> implement the visual part in HTML+JavaScript and keep the non-visual
> like it is now, in Pascal.
>
> So, the problem is that CGI apps are started for every request, correct?

Correct.

> So how should I proceed to obtain a application which will keep
> running for the entire session of a user? I don't want to simply save
> session info because the application is rather large, there are lots
> of things going on and it would be much easier for my coding if I
> could keep the program running on the web server ...
>
> Any ideas?

You MUST save the session. How the app knows about the user logged?
To keep the app running on the web server, read about FastCGI.

http://en.wikipedia.org/wiki/FastCGI
<your FPC trunk>\packages\fcl-web\src\
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Gustavo Enrique Jimenez
In reply to this post by Felipe Monteiro de Carvalho
Hi:

 I send cookies to the client. One of those cookies is a "sessionID",
a random number generated at login.
 My sequence is something like

Login
Client: username/password ->Login html button
Server: run cgi app with username/password parameters -> ¿Valid user?
->  generate sessionID, store in DB. Send sessionID to the client as a
cookie.

Transaction
Client: Product -> Search product html button (sessionID is also sent
to the server)
Server: run cgi app with product/username parameter. sessionID is
implicit, as any cookie. if username/sessionID from the client is the
same as in the DB, send data to the client.

The sessionID cookie will remain until logout or expire time. This
way, you don't have to store password in html. The sessionID cookie
must be random+hash, unique to every session. sessionID is sort of
temporal password.

Cliente: username  -> Logout html button
Server: run cgi app with username/sessionID. Verify
username/sessionID, then send an empty sessionID cookie (this will
delete the sessionID cookie in client)

Gustavo



>2011/8/1 Felipe Monteiro de Carvalho <[hidden email]>:
> Hello,
>
> This is kind of a theorical question, but I though I'd ask before
> starting to code =)
>
> Basically I have a desktop app which I need to retrofit into a
> web-app. My idea is to cut it in a visual and a non-visual part and
> implement the visual part in HTML+JavaScript and keep the non-visual
> like it is now, in Pascal.
>
> So, the problem is that CGI apps are started for every request, correct?
>
> So how should I proceed to obtain a application which will keep
> running for the entire session of a user? I don't want to simply save
> session info because the application is rather large, there are lots
> of things going on and it would be much easier for my coding if I
> could keep the program running on the web server ...
>
> Any ideas?
>
> thanks,
> --
> Felipe Monteiro de Carvalho
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Andrew Brunner
On Mon, Aug 1, 2011 at 10:07 AM, Gustavo Enrique Jimenez
<[hidden email]> wrote:

> Hi:
>
>  I send cookies to the client. One of those cookies is a "sessionID",
> a random number generated at login.
>  My sequence is something like
>
> Login
> Client: username/password ->Login html button
> Server: run cgi app with username/password parameters -> ¿Valid user?
> ->  generate sessionID, store in DB. Send sessionID to the client as a
> cookie.
>
> Transaction
> Client: Product -> Search product html button (sessionID is also sent
> to the server)
> Server: run cgi app with product/username parameter. sessionID is
> implicit, as any cookie. if username/sessionID from the client is the
> same as in the DB, send data to the client.
>
> The sessionID cookie will remain until logout or expire time. This
> way, you don't have to store password in html. The sessionID cookie
> must be random+hash, unique to every session. sessionID is sort of
> temporal password.
>
> Cliente: username  -> Logout html button
> Server: run cgi app with username/sessionID. Verify
> username/sessionID, then send an empty sessionID cookie (this will
> delete the sessionID cookie in client)

I agree with this one.  The only thing I could add would be AJAX &
WebSockets for really advanced applications.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Gustavo Enrique Jimenez
In reply to this post by Gustavo Enrique Jimenez
Hi:

  If you don't want to use cookies, you could write the sessionID in a
hidden field in every html form (cgi app must write this hidden field
in every form). Or, if you use ajax, you could attach the sessionID to
every link (cgi app must write the sessionID parameter in every link).

Gustavo


2011/8/1 Gustavo Enrique Jimenez <[hidden email]>:

> Hi:
>
>  I send cookies to the client. One of those cookies is a "sessionID",
> a random number generated at login.
>  My sequence is something like
>
> Login
> Client: username/password ->Login html button
> Server: run cgi app with username/password parameters -> ¿Valid user?
> ->  generate sessionID, store in DB. Send sessionID to the client as a
> cookie.
>
> Transaction
> Client: Product -> Search product html button (sessionID is also sent
> to the server)
> Server: run cgi app with product/username parameter. sessionID is
> implicit, as any cookie. if username/sessionID from the client is the
> same as in the DB, send data to the client.
>
> The sessionID cookie will remain until logout or expire time. This
> way, you don't have to store password in html. The sessionID cookie
> must be random+hash, unique to every session. sessionID is sort of
> temporal password.
>
> Cliente: username  -> Logout html button
> Server: run cgi app with username/sessionID. Verify
> username/sessionID, then send an empty sessionID cookie (this will
> delete the sessionID cookie in client)
>
> Gustavo
>
>
>
>>2011/8/1 Felipe Monteiro de Carvalho <[hidden email]>:
>> Hello,
>>
>> This is kind of a theorical question, but I though I'd ask before
>> starting to code =)
>>
>> Basically I have a desktop app which I need to retrofit into a
>> web-app. My idea is to cut it in a visual and a non-visual part and
>> implement the visual part in HTML+JavaScript and keep the non-visual
>> like it is now, in Pascal.
>>
>> So, the problem is that CGI apps are started for every request, correct?
>>
>> So how should I proceed to obtain a application which will keep
>> running for the entire session of a user? I don't want to simply save
>> session info because the application is rather large, there are lots
>> of things going on and it would be much easier for my coding if I
>> could keep the program running on the web server ...
>>
>> Any ideas?
>>
>> thanks,
>> --
>> Felipe Monteiro de Carvalho
>> _______________________________________________
>> fpc-pascal maillist  -  [hidden email]
>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>>
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE : [fpc-pascal] web app and application persistency

Ludo Brands
In reply to this post by Michael Van Canneyt
> > So how should I proceed to obtain a application which will keep
> > running for the entire session of a user? I don't want to
> simply save
> > session info because the application is rather large, there
> are lots
> > of things going on and it would be much easier for my coding if I
> > could keep the program running on the web server ...
> >
> > Any ideas?
>
> If you really want the application running 100% of the time,
> there are only 2 options:
> - fastcgi with mod_fastcgi (NOT mod_fcgid) and
> ExternalFastCGIServer option.
> - Embedded server (i;e. the application acts as a webserver).
>
> Both ways are supported with fpWeb. I use fastcgi.
>

Currently I'm working on project that uses a small (fast)cgi module that
sends and receives data over a socket to the application that is running in
the background.  A 3rd option.

Ludo  

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Felipe Monteiro de Carvalho
In reply to this post by Andrew Brunner
On Mon, Aug 1, 2011 at 5:23 PM, Andrew Brunner
<[hidden email]> wrote:
> I agree with this one.  The only thing I could add would be AJAX &
> WebSockets for really advanced applications.

Do WebSockets allow to use TCP sockets in JavaScript or is it something else?

--
Felipe Monteiro de Carvalho
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Marco van de Voort
In reply to this post by Andrew Brunner
In our previous episode, Andrew Brunner said:
> > username/sessionID, then send an empty sessionID cookie (this will
> > delete the sessionID cookie in client)
>
> I agree with this one.  The only thing I could add would be AJAX &
> WebSockets for really advanced applications.

I thought websockets were disabled in most current browsers due to security
concerns?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Andrew Brunner
In reply to this post by Felipe Monteiro de Carvalho
On Mon, Aug 1, 2011 at 10:43 AM, Felipe Monteiro de Carvalho
<[hidden email]> wrote:
> On Mon, Aug 1, 2011 at 5:23 PM, Andrew Brunner
> <[hidden email]> wrote:
>> I agree with this one.  The only thing I could add would be AJAX &
>> WebSockets for really advanced applications.
>
> Do WebSockets allow to use TCP sockets in JavaScript or is it something else?

WebSockets are persistent connections that never close unless
directed.  Plus the server can push data over the socket and the
client can process data on an event basis.

HTTPRequest is query response.   WebSockets is asynchronous and
perfect for event driven programming over the web.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Michael Van Canneyt


On Mon, 1 Aug 2011, Andrew Brunner wrote:

> On Mon, Aug 1, 2011 at 10:43 AM, Felipe Monteiro de Carvalho
> <[hidden email]> wrote:
>> On Mon, Aug 1, 2011 at 5:23 PM, Andrew Brunner
>> <[hidden email]> wrote:
>>> I agree with this one.  The only thing I could add would be AJAX &
>>> WebSockets for really advanced applications.
>>
>> Do WebSockets allow to use TCP sockets in JavaScript or is it something else?
>
> WebSockets are persistent connections that never close unless
> directed.  Plus the server can push data over the socket and the
> client can process data on an event basis.
>
> HTTPRequest is query response.   WebSockets is asynchronous and
> perfect for event driven programming over the web.
..But it is not always supported by the browser (as Marco indicated)
and many firewalls simply don't agree with websockets.

So unless you have absolute control over these parameters,
it's a bad idea to rely on websockets.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Andrew Brunner
On Mon, Aug 1, 2011 at 12:05 PM, Michael Van Canneyt
<[hidden email]> wrote:
> ..But it is not always supported by the browser (as Marco indicated)
> and many firewalls simply don't agree with websockets.
>

Can  firewalls detect websockets over port 80?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Michael Van Canneyt


On Mon, 1 Aug 2011, Andrew Brunner wrote:

> On Mon, Aug 1, 2011 at 12:05 PM, Michael Van Canneyt
> <[hidden email]> wrote:
>> ..But it is not always supported by the browser (as Marco indicated)
>> and many firewalls simply don't agree with websockets.
>>
>
> Can  firewalls detect websockets over port 80?

Any reason why it should not detect it ?

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Andrew Brunner
The only thing I can think of would be packet inspection.  Firewalls
included with Linux and Windows do not perform "deep" packet
inspection.  They only allow/deny packets with specific ports over
either TCP or UDP.

Am I missing something?

On Mon, Aug 1, 2011 at 12:31 PM, Michael Van Canneyt
<[hidden email]> wrote:
> Any reason why it should not detect it ?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Graeme Geldenhuys-2
In reply to this post by Michael Van Canneyt
On 1 August 2011 16:32, Michael Van Canneyt wrote:
>
> If you really want the application running 100% of the time, there are only
> 2 options:
> - fastcgi with mod_fastcgi (NOT mod_fcgid) and ExternalFastCGIServer option.
> - Embedded server (i;e. the application acts as a webserver).

...and option 3.
Application on the server (as a daemon or service or something), and
the CGI app is simply acting as a proxy. I did test this in a small
test case and it worked well - no idea how well it will scale though.

But the other two options are probably easier to program.


--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Marcos Douglas B. Santos
On Tue, Aug 2, 2011 at 6:51 PM, Graeme Geldenhuys
<[hidden email]> wrote:

> On 1 August 2011 16:32, Michael Van Canneyt wrote:
>>
>> If you really want the application running 100% of the time, there are only
>> 2 options:
>> - fastcgi with mod_fastcgi (NOT mod_fcgid) and ExternalFastCGIServer option.
>> - Embedded server (i;e. the application acts as a webserver).
>
> ...and option 3.
> Application on the server (as a daemon or service or something), and
> the CGI app is simply acting as a proxy. I did test this in a small
> test case and it worked well - no idea how well it will scale though.
>
> But the other two options are probably easier to program.

It's call _CGI gateway_ and I think this is a good option because you
can redirect the CGI to another app/server/information when you stop
the app service on the server.

Marcos Douglas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Jorge Aldo G. de F. Junior
In reply to this post by Andrew Brunner
You can use L7 filtering to select actions based on packet content.

2011/8/1 Andrew Brunner <[hidden email]>:

> The only thing I can think of would be packet inspection.  Firewalls
> included with Linux and Windows do not perform "deep" packet
> inspection.  They only allow/deny packets with specific ports over
> either TCP or UDP.
>
> Am I missing something?
>
> On Mon, Aug 1, 2011 at 12:31 PM, Michael Van Canneyt
> <[hidden email]> wrote:
>> Any reason why it should not detect it ?
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: web app and application persistency

Marco van de Voort
In reply to this post by Andrew Brunner
In our previous episode, Andrew Brunner said:
> The only thing I can think of would be packet inspection.  Firewalls
> included with Linux and Windows do not perform "deep" packet
> inspection.  They only allow/deny packets with specific ports over
> either TCP or UDP.

Usually they deny all ports by default and route 80, 8080 and 443 to a
proxy, which *does* understand http.

It might be that websockets are too much like normal http requests that a
proxy will put them through, but I'd check that before betting  on
websockets.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal