Rev cgi search question

Tue Jan 15 10:47:40 EST 2008

Richard,

using 'launch' is not advisable. Not only every instance of your cgi
will start it's own program but there's a big chance that your cgi is
running as 'nobody' or 'apacheuser' or some other very limited user on
your server (this is a good thing, it's security wise to put the cgi
user on a sandbox of sorts). If you want to run a persistent software
on your server, you must do it with text file scripts and revolution,
trying to run stacks or standalones will try to connect to the X11
server and unless you're running a framebuffer display server, this
will fail and your software will fail to start with it.

If you're thinking about running a software to cope with your previous
search result issue, then let me say that you don't need it.

The idea to solve this kind of trouble is to have session variables.
This variables are assigned to each of your clients and you can store
useful information in them. Revolution does not provide us with
session variables from the start but with minimal effort you can
create your own. In my RevOnRockets package (
http://www.andregarzia.com/RevOnRockets ), I have a minimal
EasySession library that can help you.

My current session library implementation is not in sync with
EasySession. What I am using today is plain stack files. Each stack
file holds a session. The name of the file is a unique id and I pass
this name in the SessionID url parameter or a cookie. I have two
functions one for setting a value and one for getting a value. My
library has lockfile features, so a user with two browser windows open
(and maybe the same session on both) will not overwrite himself.

whenever I need to store some value, I call my value setting function
which not only sets the value taking care not to overwrite other
changes being made but it also save the file, so once the value is
set, it is not lost anymore. Getting values is easy, we don't need to
check anything, we just pull the value from the stack and thats all. I
use custom properties to hold values.

You may ask, "Why, Oh Brazilian Fool, are you using stack files
instead of a database?" and the answer is quite simple. First, I like
stacks. Second, session variables don't usually need heavy concurrent
access or fort knox level security. You just use it to store simple
data, if you need security you use a database and make a pointer in
the stack file like myDatabaseId = '#23525' so your database record is
safe and your session still contains the parts needed to construct the
information you need.

The main benefit of databases in my very humble opinion are:
* many users changing the same resources.
* searches!

With session variables you have only one user changing his own session
and you don't need searches, so, I guess we don't need a RDBMS
afterall.

Now, there are other ways if you digg into Javascript. You can use a
hidden div to hold all your search data and use javascript in
combination with xmlHTTPRequest to move things around. I don't know if
this is overkill though.

The RevOnRockets package comes with EasySession that uses text files
instead of stack files and has no lockfile features so it is possible
to overwrite changes if a user has two browser windows open with the
same session. Still it is good enough for simple sessioning. With
EasySession each session is write-once-read-once, or in plain english:
you set a session then you read it afterward and when you read, it is
deleted, if you want to move what you read forward then you need to
set it again. This was done for security purposes so that sessions
can't be re-used. If some hacker picks your url with a session id,
there's no problem because that session has a great chance of not
existing anymore.

So what easy session is good for? Moving secret data from one page to
another. In one page you set the data, for example credit card number,
user information and when moving to the next one, you pass the session
id. In this page, the data is read and session is cleared. Your url
and your post/get requests hold no sensitive information. I've created
this library mostly for doing confirmation pages where the user fill
data, then he is moved to a confirmation page, then the data is
proccessed. This way, I simply set the session on one page and clear
it on the next, the sensitive data is held on server for a very brief
time, just the interval when the user is in transit from one page to
the other since in each page the session is cleared. It is hard to
capture this session and impossible to re-use it. Feel free to
download RevOnRockets and check on EasySession.

I hope this helps.

Andre

On 1/15/08, Richard Miller <wow at together.net> wrote:
> Thanks.
>
> A few other questions about using Rev in the cgi-bin.
>
> Can a Rev cgi script use the "launch" command to run a small Rev app
> from inside cgi-bin?
>
> Do I understand correctly that several instances of the Rev cgi
> application can be running concurrently? In other words, the server
> could be simultaneously processing the requests from several users,
> but each request would cause the Rev app to start its own instance.
> Is that right?
>
> Thanks.
> Richard
>
>
> On Jan 14, 2008, at 8:41 PM, Kee Nethery wrote:
>
> > We do stuff like this all the time. caching data locally.
> >
> > The deal is we store last datetime changed for each row in each
> > table in our database. Every time the row gets changed the datetime
> > gets updated.
> >
> > The various systems that use the data search the local data cache,
> > not the external database.
> >
> > Before doing the search we do an update to the cache and to do that
> > we keep track of the lastdatetime when the database was looked at
> > and we look for any rows that have changed since then. If the
> > result set is zero, then the cached data gets used as is and the
> > lastdatetime gets incremented in the cache.
> >
> > If the resultset is not zero, we grab the changes, and incorporate
> > them into the data set and then update the cache date.
> >
> > Then once the cache is updated, we do the search.
> >
> > If the cache is empty, or the last cache check date is empty, we do
> > a complete pull from the database.
> >
> > Kee
> >
> >
> > On Jan 14, 2008, at 11:28 AM, Richard Miller wrote:
> >
> >> I'm looking for suggestions on how to accomplish the following.
> >>
> >> 1. User starts a search of my text-based database (via browser and
> >> Rev cgi).
> >> 2. My app finds the results (which are a series of line numbers...
> >> possibly as many as 1000)
> >> 3. I now want to store those results so that when the user brings
> >> up a data page resulting from the search, they can go back to the
> >> results (presumably to go to another data page from the results)
> >> without having to re-do the search or use the back-button on their
> >> browser. I know how to store the results within a link (i.e.
> >> http://www.results.com?results=1,2,3..."), and I'm using this in
> >> various places already. But this won't work for me in all cases.
> >>
> >> I'm guessing one solution might be to issue a temporary id number
> >> and connect that to a given users search process. The results
> >> could then be stored in a file on the server under this ID, with
> >> this page liquidated after some period of time (30 minutes? 60
> >> minutes?). Would this work or is there a better way to handle this.
> >>
> >> Thanks.
> >> Richard Miller
> >> _______________________________________________
> >> use-revolution mailing list
> >> use-revolution at lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-revolution
> >
> >
> >
> >
> > -------------------------------------------------
> > I check email roughly 2 to 3 times per business day.
> > Kagi main office: +1 (510) 550-1336
> >
> >
> > _______________________________________________
> > use-revolution mailing list
> > use-revolution at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-revolution
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

-- 
http://www.andregarzia.com All We Do Is Code.