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:
- The various users you mention are using the same browser and hence share cookies. Obviously this would only happen during testing. If you want to simulate multiple users from the same computer, you can do so by using a different browser make for each user (e.g. IE and FireFox). Another possibility is to use the same make, but start a different browser from the Start menu (versus opening a new window from the browser's File menu).
- Another possibility is that you are using public variables to store session information. If this is the case, please read the chapter on public variables in the FoxWeb documentation.
FoxWeb Support Team
support@foxweb.com email |
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:
Response.Write("Hi there!")
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.
FoxWeb Support Team
support@foxweb.com email |
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.