IP Address using VFP instead of manually heading to whatismyip.com 3

[dantheinfoman]

Hi All,

I've been searching quite a bit this morning to find a way to get the ip address of a person/business' internet, not the local ip that's similar everywhere like 192.168. . .

I can find the local IP all over the net. What I can't find is how to get the external ip, such as what you find when you visit

http://www.whatismyip.com.

I'm trying to get the ip address of the user who is manually editing a certain record in addition to the username.

Thoughts??

thanks

Dan

 

[JRB-Bldr]

who is manually editing a certain record

I'd suggest that for this your best approach would be to create a Logging routine which captured the WorkstationName + Username + RECNO() into a separate Log table.

The WorkstationName + Username is easy to get with SYS(0)

I assume that, since your previous question was about WINSOCK, you already know how to get the Local IP.

oSock = CREATEOBJECT("MSWinsock.Winsock.1")
? oSock.LocalIP

Since the External IP Address is only 'seen' outside of the Domain, under what circumstance would you need to get it?

Good Luck,
JRB-Bldr

 

[dantheinfoman]

This is because the client wants the IP on there, I would suggest using the PC name etc as well. Not sure if they'll go for it.

Thanks if anyone knows how to obtain this. Worst case scenario is we somehow make a field in a control file where this has to be manually entered?! I don't like that method though.

Thanks

Dan

 

[JRB-Bldr]

The reason for my question is that the VFP application will not be accessing the VFP Data Table from "outside" of the Domain.

Even if the user was accessing things across an Remote Desktop (RDP) connection, from the application's perspective it would be "inside" the Domain and therefore the External IP would not be "visible".

So I ask again, under what circumstance(s) would the VFP application itself be 'external' to the Domain where the VFP Data tables resided?

Good Luck,
JRB-Bldr

 

[dantheinfoman]

Hi jrbbldr,

If you need to submit clock ins, clock outs and edits to a state billing agency and they demand ip addresses for edits or clock punches, I'd think they want the external id to verify where you were clocking in/out or editing a record from. If you were on a mobile device, this is easier, but if edits/punches come from a pc, I don't know how to give them an ip address to tie the location/id of the punch. If they see a bunch of 192.168.1.20 type stuff, I don't think they'll be pleased.

Thanks for your input.

Dan

 

[SytzedeBoer]

This is what I do

loExplorer = Createobject("InternetExplorer.Application")
loExplorer.Navigate2("

http://www.whatismyip.com")

Do While loExplorer.readystate <> 4
ENDDO
loDoc = loExplorer.Document
MyPublicIp =UPPER(loDoc.Body.Innertext)
m.lcReturnYourIP = "UNKNOWN"

If ATCLINE("YOUR IP",MyPublicIp) > 0
ml=ATCLINE("YOUR IP",MyPublicIp)
m.lcReturnYourIP=MLINE(mypublicip,ml)
Endif
=MESSAGEBOX(m.lcReturnYourIP,'')

 

[JRB-Bldr]

If the user was utilizing a VFP application to edit the record, it would need to be running within the Domain where the Data Tables were accessible.

to verify where you were clocking in/out or editing a record from.

Unfortunately if the VFP application was being accessed through RDP, no matter how, it would 'appear' as a within-the-Domain workstation and user regardless of where physically the user might be.

There is a Command line that you can use within the RDP workstation to find what is connected to it.
Something like:

SET logfile="rdp_ip_logs.log"
date /T>>%logfile%
time /T>>%logfile%
netstat -n | find ":3389" | find "ESTABLISHED">>%logfile%

Then have the VFP application 'read' the Log File.
NOTE - I have not tried this myself with an actual 'external' RDP workstation. With an 'internal' RDP workstation it worked fine. I'll leave that to you to test and get back to us.

However, if the user was using something else like a VB.ASP (web-based) 'application' to access the VFP Data Table, then that is an entirely different thing and would need to be addressed in a completely different manner.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

Within a LAN the LocalIP in the typical private address spaces (Homenetwork 192.168.0.0 – 192.168.255.255, Office 172.16.0.0 – 172.31.255.255 Corporate 10.0.0.0 – 10.255.255.255) is fine.
Indeed the external IP of a whole LAN could be identical, if there is one major internet access point, so it is NOT an ip to identify a computer in the LAN.
Ever heard of NAT?

A smaller LAN may just have a router with Internet access and a few computers attached to that, maybe even wireless. A larger LAN may have a demilitarized zone (DMZ) between LAN and WAN or Internet.

For a company software computer names can work OK, too. IP addresses can be dynamically assigned by DHCP, so that would only temporarily identify a network PC, the name is actually better.

Bye, Olaf.

 

[Olaf Doschke]

I assumed you want to identify some PC within a LAN. If you want a world wide unique identifier, create one: Create a GUID and store that in the registry. Also the external IP is dynamic in very many cases. Corporations may have a static ip there, but there's not one for every PC client.

Bye, Olaf.

 

[JackTheC]

A simplefied solution for external IP address:

safefile='c:\saveip.txt'
url='[URL unfurl="true"]http://myip.dnsdynamic.org/'[/URL]

declare LONG URLDownloadToFile IN URLMON.DLL LONG, STRING, STRING, LONG, LONG

GetResults=URLDownloadToFile(0,url,safefile,0,0)

if GetResults=0
	res=filetostr(safefile)
else
	res='' 
endif

erase (safefile)

return res

 

[atlopes]

An alternative to the methods already posted:

LOCAL loIP AS Micrososoft.XMLDOM
LOCAL lcIP AS String

m.lcIP = "Service not available"

TRY

	m.loIP = CREATEOBJECT("Microsoft.XMLDOM")
	m.loIP.async = .F.

	IF m.loIP.load("[URL unfurl="true"]http://checkip.dyndns.org/")[/URL]
		m.lcIP = m.loIP.selectNodes("//body").item(0).text
		m.lcIP = ALLTRIM(SUBSTR(m.lcIP,AT(":", m.lcIP) + 1))
	ENDIF

CATCH
ENDTRY

MESSAGEBOX(m.lcIP)

 

[dantheinfoman]

Thanks Everybody!!

JacktheC, this worked first try. Thank you atlopes for your response also!

You guys are brilliant!!!

Dan

 

[Olaf Doschke]

Dan

it's important to have an identifier, that reidentifies the computer.
Neither a local IP dynamically changing via DHCP is such an identifier, nor the external IP. It's also not static in many cases, sometimes only quasi static, changing each 24 hours or in longer intervals, but it's never an IP per computer.

Bye, Olaf.

Edit: Do you have 2 PCs? Or a PC & tablet or smartphone? Then let these connect to your WLAN and navigate to

http://myip.dnsdynamic.org/

on two of the devices, you'll see the same IP, the external IP of your network, the router or cable modem IP to the external world. It's not a per computer/device IP.

 

[JackTheC]

Thanks for the star, Dan.

Question: I tried an even smaller version:

declare LONG URLDownloadToFile IN URLMON.DLL LONG, STRING, STRING, LONG, LONG
=URLDownloadToFile(0,'[URL unfurl="true"]http://myip.dnsdynamic.org/','c:\saveip.txt',0,0)[/URL]
return filetostr('c:\saveip.txt')

I didn't erase the file c:\saveip.txt but I can't find it in C:\
The function works anyway. How come?

If I use f:\ instead of c:\ for the saveip.txt file, it does show up in f:\ however.
How can filetostr read a file that is not present?
I tried in Win8.1 and Win10.

 

[Olaf Doschke]

There most probably is a UAC redirection of file names happening. Both at write and read.
Root directories are typical candidates for redirection, the same as system directories, unless they are meant for writing to them (like public appdata or userprofile library directories).

I can write to C:\ within Windows Explorer as I am an administrative user on my workstation. Still URLDownloadToFile does not do that for me, too. I find the saveip.txt within C:\Users\myaccount\AppData\Local\VirtualStore, which is the root folder of redirected files. Why? Because I start VFP9.exe without elevation to my administrative privileges, it runs with normal access, because of not requiring adminstrative elevation in the VFP9.exe embedded manifest. So UAC works here. If it would have a manifest requiring admin level, a prompt would appear asking for my to confirm the start (as in a setup) and for normal users this prompt would even be a prompt for a login as an adminstrative user instead of just the confirm button.

Another proof: I started VFP9.exe via right click on the start menu tile and "Run as administrator". Now running the code, the file is generated at C:\, UAC is not redirecting this, as I gave the VFP9.exe process the privileges of my account and started it elevated.

The time your accounts privileges were "inherited" by every process you start are over since Vista. Running XP as adminstrative user (not only as THE Administrator account) you ran every single process you started with administrative rights, so you gave every single process the right to do anything on your system. That got restricted via UAC as safety against anything becoming active with high priviliges hidden, without your notice. Hackers might laugh at this safety by now and still have several unpublished and unfixed backdoors to any system, but don't underestimate the protection level of UAC, this surely saves you from harm.

I see it that way: Windows got more and more stable, and that's not only de to the fact anti virus protection got better and better. MS also avoids several things otherwise undermining the system stability. In Windows a root folder has not the same meaning as in a Unix system, where the file system itself only has one root / and everything is mounted not as drive letter but at some level of the whole directory tree. This is where rootkits as tools for administrative access in a system have their name from as getting the most privileged root level to a system.

UAC is about 10 years old now, and this is the first time you actually saw a file redirection? Then it's working quite silent, isn't it? You don't get an error about writing to a folder you're not permitted, your write and your reads are redirected. That's also enabling legacy software to have data within application folders in C:\Program Files\ though only setups should write there during installation.

Finally: You should in no way now think you should delete the whole VirtualStore folders because it only contains file generated in an attempt to get hands on your system or such. Even MS software has some things redirected there and it's not bad in itself. It also means the files are per user, as the VirtualStore is in the user profile. This means even software intended for multiple users on the same system can have a per user configuration or database, which also can be a pain.

As developer you should know where to store what and then won't even be affected by this.

Bye, Olaf.

 

[JackTheC]

Thanks Olaf for the comprehensive explanation. Star. Indeed the file was in C:\Users\myaccount\AppData\Local\VirtualStore.
Never knew that AFAIK. Of course in my code snippet C:\ was just an example of a folder that exists on all or on most PC's.
B.t.w. I always set UAC to no notificatons on my PC. Not that it matters in this case.

 

[Olaf Doschke]

Since UAC takes care of not really writing to C:\ no problem. A normal place for such temporary info would be GETENV("TEMP"). Many tools like CCleaner or even the system will clean this once in a while.

Bye, Olaf.