Peter: While your solution below is elegant and clever, do you realize how inherently ridiculous it is? I can just see myself trying to explain this to a customer, "No, we don't use CSP for the login because it can't handle the kind of standard behavior a web user expects." The next question out of the customer's mouth would be something like, "Well, why don't you just write the app in ASP/Perl or whatever!" A good solution to a ludicrous problem. -- John Bertoglio Senior Consultant co-laboratory office: 503-538-8691 mobile: 503.330.6713 fax: 503.538.8691 www.co-laboratory.com
"Peter Cooper" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Gertjan > > > I recently came across this - very small no of users on an internal > intranet with csp. > typically they log on and stay on all day - 8 hour session timeout > > Buy exactly the license count that matches the number of users > > if all is OK - fine > but if they closs cross the browser or crash or want to open another > browser window > > they need a spare license in order to see the logon screen - so they > can get logged on and then do the normall license trading upto 12 > connections from the logged on user > ==== > I had a thought on this - maybe when I have time will play > > make the logon-screen a non-csp app (asp,perl whetever), the > username/pasword is checked via a Cache Factory or ODBC stored > procedure call > if the password is OK then redirect to the Cache app - session starts > at this point > > this also has the advantage that hackers cannot mount a DoS attack on > the login screen cos it's non-Cache and consumes no licenses - and you > have to have a valid logon to get into the csp app > > Peter > > > > On Tue, 17 Aug 2004 17:51:45 +0200, Gertjan Klein <[EMAIL PROTECTED]> > wrote: > > >Bill McCormick wrote: > > > >>Because the background CSP process is not using a license - remember the > >>license is held by the session, not the process - we take a license on > >>the jobbed process by default. Then you can tie it to whatever you like > >>through the available API's. > > > >This makes sense, but has the unfortunate side-effect that at least > >one free license slot must exist to start a job from a CSP page, even > >though this job shouldn't (and won't - after the login) take up a > >license slot. > > > >Doing the login *before* the Job prevents this requirement for an > >extra license slot, but presumably permanently ties the CSP process to > >a license, which seems undesirable. I have not found a way to return > >the CSP process to it's state of not using a license connection after > >the Job. > > > >Do you know of a workaround that removes the requirement of a free > >license slot without tying the CSP process to a license? > > > >Gertjan. >
