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,

Correct.

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

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.

Correct.

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\

Hi:

I send cookies to the client. One of those cookies is a "sessionID", a random number 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

I agree with this one. The only thing I could add would be AJAX & WebSockets for really advanced applications.

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 :

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

Andrew Brunner 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?

In our previous episode, Andrew Brunner said:

I thought websockets were disabled in most current browsers due to security concerns?

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.

Michael Van Canneyt 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.

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?

Michael Van Canneyt wrote

Any reason why it should not detect it ?

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

You can use L7 filtering to select actions based on packet content.

2011/8/1 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.