Getting IP from CGI or other method

Hello there Ozzu community! I am currently in development of my first major web project, an Archmage like prof of concept. I am, however, a little lost on one subject, the being the tracking of users.

I really would like to see the IP address of the caller of my CGI scripts. Does anyone know a way this can be done? Or does anyone know of a method that is not CGI? Any help would be most appreciated.

This project is being developed under the Apache HTTP Server, version 2.0 on Windows 2000 using (currently) only CGI to talk to the web server.

Thanks,
QBRADQ

what language is it in? If its perl , you can use
$remote_ip = $ENV[REMOTE_ADDR];

if your using php, its
$remote_ip = getenv("REMOTE_ADDR");

Thank you for your reply! I am actualy using C, but I do know how to access the environmental variables. Thank you again.

"Why C?" you may ask? Because C is a compiled language. Call me crazy, but I like that

But here's the real zinger. Suppose I have two accounts on this service, both logged in from the same IP address (I.E., they are behind a local router splitting out a cable line, such as the network I am testing this from).

Now, my origional plan was to associate a logged-in user with his/her IP address, and to access that user's data based on the IP that was comming into the CGI scripts. With this kind of setup, if someone else tried to log into another user within the same network, I would see an IP that already has a user assinged to it.

Any ideas about how to get around this? I thought of implementing a kind of session ID system similar to the PHP4 session management functions. I even have a working implementation of this system in PHP. However, my web guy is already pounding his brains in trying to remeber CSS while interfacing with my CGI scripts. Adding PHP or, worse yet, a custom session management mechanism would make his head explode

Thank you again for your response,
QBRADQ

I had a look into using C but I don't recommend it. I spent a few days trying it out and my C program ran about twice as fast as my perl version.

That may seem like a lot but if you ask me its not worth the extra time it takes to write it.

As for your other question, the environment variable you want is
HTTP_X_FORWARDED_FOR

but I'm not sure exactly how you use it.

Thank you for the tip on HTTP_X_FORWARDED_FOR. I am looking into it now.

Also, I would like to ask about your prior experiance with C. Do you have a lot of experiance, or are you just familiar with the syntax and libraries? I find it a <b>lot</b> faster to write a CGI in C than Perl, mainly because I know C very well, and don't know Perl that well.

As a side note, I am currently considering doing the entire project in PHP. It may not be as fast as C, but it's got what I am looking for. Mainly a well documented and easy to use MySQL API. Also, my web guy has agreed to learning enough PHP to be able to intergrate his html/css stuff with all my "Stupid coder crap" as he put it I feel that this way, the development of the system will be very simplified.

Just to clarify my structual design concept (mainly as an exercise to make it more clear to myself), I will outline both the previous structual design and the new design below.

Previous Design: HTML / CGI / PIPESERV / MySQL Server

HTML pages contain forms which call out to specific-purpose CGI scripts written in C.

CGI scripts parse the information from the forms and sends a request to PIPESERV to do all applicable processing. (Communicates using calls to multi-threaded named pipes on the local machine, managed by PIPESERV)

PIPESERV maintains named pipes and linkage to MySQL Server, as well as all needed memory blocks and mechanics code, thus reducing the load and execution time of the CGI scripts. Communicates to MySQL Server to retreave information either requested by the CGI script or needed by the function/s requested by the CGI script.

MySQL Server maintains state information about user accounts, global influances, ect.

New Design: HTML with PHP / MySQL Server
HTML pages contain forms for requests, which are carried out by PHP scripts. PHP directly accesses the MySQL Server, as well as carring out any game mechanics that need to be done within one script.

MySQL Server maintains state information about user accounts, global influances, ect.

I believe that the new design will be a lot easier to maintain. The method employed to orgonize all of the source code for the origional implementation involved using MSVC 6 in a way other than recommended, if you understand where I am comming from, as well as a server process (PIPESERV) ran in addittion to the MySQL Server.

The new design will use one PHP IDE, the web server, and the MySQL Server, as well as a MySQL GUI Frontend for local debugging of scripts. This design will also make tracking down bugs a <b>lot</b> easier.

Tell me what you think.

Also, if anyone knows of a good, and free PHP IDE, shoot me a link. I managed to find one about three months ago that I was just in love with. However, at the time I really didn't have a need for PHP as I did not develop web content, and as such the installer got lost in my file system.

Thank you,
QBRADQ

CGI is old news anyway, don't bother. If you're going to take the time (and therefore know how) to write CGI in C, you can probably just write PHP extensions.

PHP on IIS runs as CGI, which makes it not much slower than when run as an Apache Module, but that's not an issue for you anyway. My point is, scrap CGI scripts and use Server-Side scripting.

"It's good, and it's great. And what's more, it's right!"

.c

I know this will probably sound stupid but doesn't an ISP change your IP address through out a session on the net? Asking this because linking an IP to USER for the validation will fall over every time the IP address is changed.

Just wondering

no, when you connect you get an IP, and when you disconnect the ISP takes it back. At least that is correct in at least 90% of cases.

Between sessions you would have to enter your password again.

ISP assign your IP when you connect (assuming you're not paying extra for a static IP... in which case you're IP would always be the same) using a system called DHCP (Dynamic Host Configuration Protocol).

When you disconnect from the ISP, or are forceably disconnected for any reason, the IP you were using is available for re-assignment to another user and 99.9% of the time, when you reconnect, you will have a different IP address.

However, while you are connected, you will not be given a new IP address by your ISP. If, for some reason, they do need to assign you a new one, you're internet connection will simply drop. Sort of like calling your credit card company because you're card was stolen. They issue you a new number, and you have to go around changing any auto-charge accounts... (hehe, ok, that analogy was a bit weak... but you get my point..)

Don't confuse ISP/Internet session with a website user session. A user session is initiated the first time you request anything from a web server. In general, a webserver will create a session ID based on a whole number of factors, on of which is your IP, it uses the datetime of your request, and usually some internally seeded random number, all of with is magically encoded into a long and unique string of characters.

This session value is, generally, valid until 15 minutes (or whatever the session timeout value for a given webserver is... 15 is usually the default) has passed between any HTTP request OR until your web browsers is closed (another criteria has something to do with the brower.. I haven't figured that one out... is it some sort of process id? anyway...). If one of those happens and you go back and make another request, a new session will be created for you. If you're using session scope variables (cookies can be session scope as well, by the way, it depends on how you initialize them. They are session scope by default, I believe) to hold login data, when your session expires, so will the login. To do the "remember me" thing, you have to set a cookie that doesn't expire when the session ends. You can do this with JavaScript, PHP, ASP... whatever. Generally, it's as easy as simply setting a cookie expiration date way in the future (the default, no expiration date set, makes the cookie session-scope).


Probably more info than you needed... =]

.c

Thanks for that.

It is just I was doing research in doing the same sort of user validation QBRADQ was doing and on my travels I saw that it is not a good idea to do it that way.

Ah, I see. IP is sort of like identifying someone based only on their hair color... Not the best way to do it. The truth is, except for a login system, there is really no sure way to identify anyone online. Cookies are good unless people don't accept them, or are like me, and use Spybot to block most of them and manually delete them all at least once a week..

Every thing else is more or less session-scope, which is accurate enough, but only for a session.
.c