[Xitami] CGI trouble - identical cfg - different execution
MRJ InfoTech Admin
admin at mrjdesign.net
Sun Feb 12 12:52:33 CET 2006
Further, VERY odd behaviors are now noted in this execution.
I loaded the entire load of data for testing over to the server machines
root directory.
Now, it is loaded in to the default directory of Xitami, bypassing any
virtual host paths and so on.
This in it self should not have any bearing on the serving of pages, let
alone the execution of the very same code.
After all I can easily pull the same information in a JS page or similar
script without any issues.
However, to further complicate the issue.
The server box is running through dual NICs
Assume for the sake of conversation that I have a
http://localhost which is 127.0.0.1
Then I have two (2) IP addresses which are public (Static) to the internet
10.0.0.99 and 10.0.0.98
(of course these are fictitious and should be (83.###.#.##) and something
else but it's an example)
When I execute the CGI on 127.0.0.1/MyPage.htm and send the call by a
simple GET to the CGI-BIN the code works perfectly!
Not a single fault anywhere to be seen.
When I execute the code on 10.0.0.99 it bumps me around saying, I executed
from a non permissable CGI_Referer
HA... the code actually works.
I wrote a thing that disallows cross linking from other domains so you
can't run the cgi embedded in an other web site and call my pages from the
other site.
Then, thinking logically...
If the 10.0.0.99 page is disallowed, the page will thereby assume it self
as running on 10.0.0.98 in this case,
so the thread in Xitami actually waking up to the call to the page is
located on the other IP.
I opened a page in 10.0.0.98/MyPage.htm instead and executed the click by
doing a Get for the page
myCGI.exe?Param1=0&Param2=6574&Param3=9&ParamText=
is now returning the same goofball errors as before.
Previously noted above, everything picks up correctly, and is collected as
should be.
In this case, when being on the correct IP and all, the cgi doesn't even
allow me to get CG_Referer as a string.
Nor CG_RemoteAddr or any other data.
Talk about a backwards acting resolution of the system
So in conclusion.
1) I have to remove my IP blocking system and open up for cross linking or
I have to find a way to allow two or more CGI_Referer values to enable this
security feature when running Xitami on dual NIC's
2) Has anyone else had any experience with trying to limit callers from
other domains to avoid getting connections from outside URL's and IP's, and
how did you solve this?
Thankful for any hints and pointers as usual.
At 07:31 12/02/2006, you wrote:
>Now I have spent nearly a week working out some minor issues with a CGI
>configuration in VB.
>
>It is not the VB part that is causing grievances, as that I have down pat,
>however the problem is as follows.
>
>My test machine is...
>
>Win XP SP1 with Xitami 2.5 C2 running a single website in the local NAT
>It has the default configuration files for the CGI environment as left
>intact from setup.
>I have MDAC 2.8, MS Jet4.0 updates and all installed.
>
>My server, live machine
>
>has the indentical configuration as above, with two differences
>1) it has twice as much memory and drive space
>2) it also has a defaults.cfg file for defining some 10 virtual domains,
>each with the std. setup for each.
>
>One further difference in this is
>
>the workstation works fine
>
>the server station does NOT.
>
>The errors I am getting are almost ridiculous.
>
>Std. windows error #13 Type error.
>
>I pass a internal call in the cgi called CGI_UserAgent which supposedly
>returns the browser data.
>
>It works just fine on the workstation, AND on the server in an other cgi I
>wrote using the same bas file.
>
>It does not in this but gives me this error.
>
>I rem the line, recompile and try again.
>
>Then I get a problem in the very next line, saying the same thing for
>CGI_RemoteAddress
>which is just getting the visitors IP address in a string.
>
>This too, works in another cgi on both machines, but not in this one on
>the server.
>
>For reference, the CGI's use standard I/O calls and work just ok in all
>other cases.
>Only these bugs are about to drive me nuts.
>
>Does anyone have any idea as to why Xitami suddenly is so unstable??
>
>
>
>
>
>
>--
>Xitami Users Mailing List -- For Xitami support
>To unsubscribe: http://lists.xitami.org/mailman/listinfo/xitami
>
-©2005-------------------------------
MRJ Information Technology Ltd.
35 Camden High St., Camden/London, NW1 7JE
United Kingdom http://www.mrjdesign.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.imatix.org/pipermail/xitami/attachments/20060212/079e0a44/attachment.html
More information about the Xitami
mailing list