Please see our response in your other posting. If you can isolate the problem in a simplified version of your main page, this would really help us assist you with the problem.
Sent by Bob Keller on 04/19/2005 07:24:53 AM:
We've taken what you've recommended into account. However, we're still encountering situations where a user with specific login rights goes from one page to another, somehow changes access permissions and flips over into an 'admin' mode. I've been able to recreate on my development box, yet cannot see where this is happening. It's not a specific page, and it's not something that happens all the time.
There are NO PUBLIC variables defined.
Sent by FoxWeb Support on 03/28/2005 09:22:27 PM:
First of all, make sure that you are not using any of the new API objects, such as Response, Auth and Session. In order to send cookies, you must manually include HTTP headers by following the instructions in the FoxWeb 1.X documentation.
Another thing to watch for is the path of your cookies. If your scripts are not all in the same folder, then you should make sure to supply a path with your cookies. In fact, unless you want different applications on your server to have their own sets of cookies, it's a good idea to always set the path of each cookie to "/" whenever you send them to the browser. You may read details on this issue in the "Disappearing Session Variables and Cookies" section of the Common Problems page.
The only reasons you would be affected by having multiple users on your site are:
Sent by Bob Keller on 03/28/2005 09:10:58 AM:
Okay, I've gone through and removed the 'new' code from the legacy and went to using cookies to maintain state. The problem now is that when more than one person is on the site and moving page to page, or initiating a query, the other user(s) get a 'variable not found' error when moving from one page or query to another. They drop back to the calling page, hit 'refresh' and they can continue on. Each page that is brought up calls a common procedure that reads the cookies for user/session information before building the page(s). So how does it 'lose' the variable(s) after only a couple of lines after it's re-initiated?
Sent by FoxWeb Support on 03/15/2005 10:29:33 AM:
Are you using MergeTxt in conjunction with html_out to return data to the browser? Are you also using session variables at the same time? If yes, this is most probably the cause of your problem. You may not mix legacy 1.x code that utilizes html_out with code that uses the Response, Session and Auth objects introduced in version 2.0.
One possible solution would be to do a search and replace for all instances of "html_out" in your code. The new code should use the Response object instead. For example, the following code:
html_out = "Content-type: text/html" + CHR(10) + CHR(10) + "Hi there!"
would be translated to:
You do not need to include the content type header, unless your code returns a content type other than text/html (for example if you are returning PDF data). Other types of headers, such as cookies will need to be translated to use the corresponding methods of the Request object.
Sent by Bob Keller on 03/15/2005 06:16:18 AM:
I'm looking for any input regarding the running of legacy FoxWeb 1.x code on an updated FoxWeb 2.x server with the compatibility set 'ON'.
In a previous posting I noted the 'problem' of lost variables being recovered by 'refreshing' the main page. Now it appears that there's an intermittent problem with calling pages from other pages. The pages are all built with Xbase (FoxPro) code, and displayed using the legacy MergeTxt() function. When looking at the HTML code on the page previous to any error, the page is missing the next page reference that is inserted programmatically based on the page it was called from. The result is an error that "Script '.FWX' is invalid, non-existent, or has not been compiled". There is no FoxWeb error log generated for this error.
We can only recreate this error by going directly to the calling page bypassing the main page that instantiates the session variables. However, our users seem to be getting this error often enough to call us. It's hard to fix something when you cannot recreate the error generated by their actions.