Since OI is a single thread application, the oiengine can only process one request at a time and I have come across this problem: If I put the oiengine into an extended task (like coping 10,000 records from one file to another, not that I would ever do this on the net) and someone makes a internet request, the server seems returns the last page that OICGI created. This is causing me a major problem, as personal data is being shown to the wrong people.

Is there a way to clear the OICGI return buffer? Is there a setting I need to update in OI? Is there a setting I need to update on the server (nt server 4.0 SP5, running IIs) to ensure a cgi request is processed?

Thanks,

Tom Horan

Tom:

There is a setting in the NT Web Proxy server that allows you to specify urls whose responses should not be cached, suggesting that the server is otherwise caching your pages. You would hit this cache if the machine running the browser is using the proxy server to get to the IIS, that is, if the browseris inside the network with the OI machine. More likely, however, is that your browser is returning the copy it cached. It sends a request to OI, the request times out, it uses the cached copy.

See if you can hit OI without local caching or going through the proxy.

test1: while running the long query, dial aol or somebody using a machine with no history (options clear saved pages?), see if you get problem.

test2: try the same from inside network, but tell browser not to use proxy for local addresses

Try local cache only:

repeat 1 and 2 without clearing the history.

if you find it is cached in the proxy, then you will need to set the proxy-server to not cache cgi-bin\oicgi.

if it is cached locally,then it is a problem only if the same machine is used by multiple people.

Hope this helps.

Bob

The problem is actually more severe than that. OICGI has problems coping with any type of return error. Since all requests go into the system monitor line before being executed, you could find that anything that will not fit into a RUN PROGRAM "ARGUMENT" syntax will be rejected. This can result in all sorts of headaches. If the request is to large for an edit line to handle, OICGI will run the last sucessfully executed routine for you. Also, if you pass in a double quote (the " character, 0x22) the command line will truncate. You need to encode all 0x22s before passing and unencode them in your routine.

We're also finding that posts of large values are not being handles properly. Carl's tests have found a 15K limit on the size of a post. My tests show at least a 5K limit. We haven't figured out what the difference between the two value are. We are running the same version of OICGI. When the post is determined to be invalid, the last sucessfull post will again be executed.

Basically, it seems that if there is any problem with the request, instead of returning back an error, OICGI will just run the last request it could honour. We are now in the process of going through all of our code and windows to do validation checks on every request back from the server to ensure that each document we request has been properly loaded. I would strongly suggest you do the same.

akaplan@sprezzatura.com

Sprezzatura Group

Aaron,

Basically, it seems that if there is any problem with the request, instead of returning back an error, OICGI will just run the last request it could honour.

Even a request from a different user? Have I got this right? You can easily get data meant for a different user?

It seems it's possible for a maliscious person to trigger the problem on purpose. You say the solution is scripting. But what if the user turns off JavaScript?

- Oystein -

Oystein

"Even a request from a different user? Have I got this right? You can easily get data meant for a different user?"

Yes!!!

We had clients receiving confidential information of other clients. I mentioned this in my response to Tom on the Works board.

Jim

Jim,

I read the Works thread. I didn't realize it was the same thing. Tom's way of triggering the problem is different from Aaron's.

Is your JavaScript workaround foolproof? I asked Aaron about his method - what would happen if a user turned off JavaScript. But what with your method if JavaScript is off? The server side program will of course discover there's not an Id. But could the id be faked? (Excuse me if I'm asking silly questions. I don't understand all the details of your method.)

- Oystein -

The solution is not scripting. Dealing with the effects of the problem is possible through scripting, but this is not a solution and is not effective in all situations and is not an acceptable answer to the problem in any case. The customer that is having this problem expected a product a bit more robust for the more than $10,000 they paid Revelation for this.

As for the symptoms, yes, you can very easily get data from another user. If OICGI cannot execute the current request, it will return the last successfully entered request.

Tom posted a method in works to duplicate the problem, but I will post another one here just to show.

Open up two browser windows, any browser, any version.

In window 1, run any INET_ procedure that will return something back EXCEPT INET_TRACE.

Go to the server and run a program such that

For I=1 to 50000 ; Next I

. The idea is to keep the server busy long enough for you to do the next step.

Go to the second browser and run INET_TRACE.

Tell me what you get back in the second browser. It certainly won't be INET_TRACE.

It doesn't matter what the request is or who sent it.

Incidentially, there's nothing special about INET_TRACE, other than the program in window A can't be window B and using INET_TRACE in this example you'll get back a known quantity.

akaplan@sprezzatura.com

Sprezzatura Group

Oystein:

You are right.

If Javascript is turned off, then the request Id never gets checked and the client gets to read all the sensitive data misdirected by OICGI. So I think the better solution is to store an encryption key in the client's cookie, encrypt the data in the response with the same key before sending it and then have a javascrypt program decrypt it at the client side. If the client turns javascript off then he is left with mess of encrypted data.

But then I suppose there is a chance that OICGI might have misdirected the encryption key to the same person who turns javascript off. In this case we could only hope that this person has cookies turned off as well.

Jim

Aaron,

Help me get things straight. Both Tom and you show there's a problem when the engine is too busy. Tom shows it with static documents. You show it with dynamic ones. That's the only difference, right?

In addition you say that "any problem with the request" triggers the problem. That's something different. (But for all I know there might be a common reason deep down.)

A naive comment: The way you and Tom trigger the problem is to keep the engine busy with a separate process, run from the server. In the real world I assume all processes are started by users' requests. But I guess there is no real difference in how the engine is kept busy.

- Oystein -

Hi Oystein

The way you and Tom trigger the problem is to keep the engine busy with a separate process, run from the server. In the real world I assume all processes are started by users' requests. But I guess there is no real difference in how the engine is kept busy.

Correct - when this problem first surfaced there were no processes executed from the server, that's just to try and give an easily reproducable scenario.

Regards

cpates@sprezzatura.com

Sprezzatura Group

World Leaders in all things RevSoft

Jim,

Just a vague and probably useless idea: Could the system somehow make sure the previous request always was something harmless? Could one somehow intersperse real requests with quick, harmless ones? E.g you could have a separate workstation that sends harmless requests all the time. Well, that last suggestion was a joke, but is there e.g a way to precede each real request with a harmless one?

- Oystein -

Please see the reply in the WORKS discussion

How would i turn of the cache on IIs?

The resolution is now available as a pre-release in the WORKS Downloads section.

That's great news!

Now one or two of our clients bought the WDP but aren't Works subscribers (the two have never been linked publicly). How should they get the fix? Should we download it and give it to them or will you provide an alternative distribution mechanism for us to point them to?

Thank you!

amcauley@sprezzatura.com

Sprezzatura Group

World Leaders in all things RevSoft

I think what Andrew means is we have a client that didn't bother to purchase a works contract since we do all the programming and post to the site. He bought the Web Deployment pack only so how does he upgrade his system?

Obviously, at least to me, is that we give him a copy from our subscription. Still, there might be others who let their subscriptions lapse or did not renew for various reasons.

So, what he's really trying to ask is, what is the relationship between a web deployment system and a works subscription and how can a web deployment site only legally get a copy of this required fix?

I realise that in most cases upgrades are upgrades and some form of subscription is required. I would think that for critical fixes, one would be obligated to move outside the subscription channel.

akaplan@sprezzatura.com

Sprezzatura Group

[/i]World leaders in all things RevSoft and clarifying ornery Brits[/i]

View this thread on the forum...