In or order to request spesific data from one node that uses J1939 protocol, is it necessary to claim address before requesting that data? Do we also need to request PGN before that process? Or can we directly request data without requesting PGN or claiming address? Thanks.
Address claiming indicate that you are owner of the perticular address AND there is no other node with same address.
If you know the network will not have any other node with your node address, you can directly request the data. However, you will not comply with J1939 standards.
Your device will not be generic and will be specific to your own network (where you are sure that no other node is using same address).
In short, You can do away address claiming but you should not!
Yes, I can confirm that it works if you have only 2 nodes. I tested it and if you have only 2 nodes you do not need to claim an address for J1939 protocol.
Related
We are currently in the design phase of a product we are building for a hospital. We want to install a custom developed software on each computer and one on a central server. It should catch the event of updated patient information of any kind when for example a patient was edited and saved in the HIS. Then on the computer on which the patient was saved we want to display information about the patient in the locally installed software.
We thought about retrieving the HL7-event from a central server and then analyze the data and send back information to our software on the sending computer. But for this we would need the IP address of the computer that caused the HL7-event (e.g. the computer on which the patient was saved in the HIS). Is there any header in which we could find the original IP address? Or when the hospital has a central HL7-server will this give us the IP address of the originally sending computer?
Or can you think of any other way to receive an information about that a patient was saved on the same computer or by the same user? E.g. listening to outgoing traffic seems to be extremely difficult and not very clean. Another option could be to detect the sending user (e.g. AD-user or LDAP-user) but is that information documented within the HL7-event in any way?
TCP level
This is the best option I can imagine; bypassing HL7. I hope you are going to communicate on TCP level. With TCP, on receiving connection, you easily get information about clients IP address. You can use this IP for your purpose.
Custom field in Z segment
Implement ZDS segment and define some field (ZDS(2) may be) with mutual communication and pass the IP address in this field.
Use MSH(2) (Sending Application) and MSH(3) (Sending Facility)
Data in these fields identify the sending application and facility. If this is configured different on each computer in network, you can maintain a table in your database to map IP address against this data.
A digital certificate issuer says that:
- an email will be sent to "registered owners" of the domain (ex. croraf.com).
How does he know who the "registered owners" of the domain are? (and how can I tell in general who the registered owners of some domain are)
NOTE: Below that it gives the option to "send an email to admin#croraf.com, webmaster#croraf.com, hostmaster#croraf.com". So by registered owners it is meant something else (perhaps names in whois lookup of the domain).
The convention is to use hostmaster, postmaster or some other "well-known" email address at a domain which is likely to be held by an entity enabled to act on behalf of that domain.
They may also pull from the whois data. e.g. for stackoverflow.com it would be reasonable to allow the email to be sent to sysadmin-team. The whois data is fairly indicative of someone who is responsible for the domain, because anyone who can cause the domain's whois data to change has the ability to repoint their DNS authority to another service (where they presumably have the ability to modify things), making someone who has "whois-edit" permissions capable of completely subsuming the domain. Therefore, whoever they say is trustworthy is as good as anything else.
I want to request the remote address of the session user in grails. I found a question here which describes the problem (Grails find public IP address of the session user) and the answer really works. I use only request.getRemoteAddr() and I receive 0:0:0:0:0:0:0:1 in my localhost.However, what I have to do to see the real IP address of the user?
In this previous question which I have found it is said "Try looking at the output of request.remoteAddr when viewing the site from a different computer". I really don't know what this means and I need your help here. I can load the server only in my own browser and I use "localhost:8080/..."
Please,tell me how and where to get the correct request. Thanks!!!
"Try looking at the output of request.remoteAddr when viewing the site
from a different computer"
means that you will need to connect to the application running on your machine from another machine in your LAN.
If you have another machine in your LAN, you will need to find your local network IP address (use ipconfig) and from the other machine connect to this address. For example if your IP is 192.168.0.2, connect to http://192.168.0.2:8080
As tim_yates mentioned request.getRemoteAddr() may not always return the correct address due to dynamic addressing and proxy servers. However you may find the original address from various HTTP headers such as: HTTP_CLIENT_IP, HTTP_X_FORWARDED_FOR, HTTP_X_FORWARDED
Take a look at the answers to this question which provides more information about this subject.
That's the best you're going to get.
0:0:0:0:0:0:0:1
Is your local address. Also, this cannot be guaranteed to be unique to a user due to dynamic addressing and proxy servers
Orginal Question
I want to implement a voting system on my page that is open to visitors and users i.e. non-authenticated users can vote.
Is there a rails/rack (or other) solution to identify visitors for this purpose?
Summary/Result:
If you want to implement a system where a visitor can take a certain action only once, i.e. a voting system. You have to divide your visitors into two groups:
Visitors that don't want to/don't have the tools to trick voting
Visitors that don't manipulate the result can be tracked using techniques such as: evercookie, Webbrowser Fingerprinting (panopticklick) and IP-Blocking.
Gems:
https://github.com/daddyz/evercookie
https://github.com/Valve/fingerprintjs
JS:
https://github.com/carlo/jquery-browser-fingerprint
Paid-Services:
http://threatmetrix.com
Visitors that want and can trick voting
Visitors that want to manipulate the result will and can do this. Here's a example. You can set the barrier high for those visitors, but its usually easier for them to bypass those than for you to implement them. The reasons for this are perfectly outlined by the answers to this question.
Client software identification
Web browser fingerprinting
panopticklick only identify browser configuration, not human beings. Just using a different browser (IE/FF/Opera/Chrome) on the same computer, using the same browser on a different user account on the same computer (different set of installed plug-ins, so different browser fingerprint) or using a different computer will "fool" panopticklick.
This is not a weakness of panopticklick, as panopticklick does not try to identify human beings, only Web browsers.
"Private browsing mode" should make the browser fingerprint less unique.
Cookies
evercookie, just like any sort of cookie, is specific to a user account (or a computer) : just using a different account or a different computer would give you a different identity. (Different users cannot access each other cookies because of file permissions.)
"Private browsing mode", if implemented properly, will clear all cookies, including "super cookies".
IP address
Changing IP address
Some subscribers have :
a fixed IP address;
an IP address which changes rarely;
an IP address which changes if they unplug their modem for hour, days, or weeks;
an IP address which changes almost every time they reboot their modem;
an IP address which changes every 24 h, even if they do not want that (as the IP address change will break TCP connexions).
This is not made-up. I know ISP with all these different IP allocation policies. I have no statistics about the number of users in these different categories, however.
Some ISP will make you pay just to have a fixed IP address. So I believe a changing IP address is pretty much the norm in practice for most Internet users.
Proxies
Using an anonymous proxy (including Tor) will give a different IP address, just as a VPN.
But all the proxy users (or all users of a Tor exit node) will probably have the same IP address.
Shared IP address
In almost all cases, family members will share an IP address.
Most small/medium businesses have only one outside address. This has been a problem in practice with per-IP anti-spam limit for webmails.
Almost all mobile IP users share the same IP address with a few or a lot of other users. This has been a problem in practice with per-IP anti-DOS limit! The server administrator had to list outgoing IP addresses and white-list them! Whenever the mobile ISP uses a new outgoing IP address, its clients are blocked again until the server administrator adds the new IP address.
You probably do not want to play this "game".
You can use cookie, but that can be disabled and expired, or IP address to identify the visitor. This can be tricked too, and there is a chance that from larger networks, people come with the same IP (e.g. from corporate network).
Basically there is no foolproof solution. I think the IP address can be "good enough" if nothing important depends on it.
I have a web app that requires a user to have an account. This user can then vote 'once' on a specific item. However, some users are signing up for lots of accounts to 'game' the system.
Does anyone have any ideas how you can restrict this type of thing?
Could I restrict number of signups per day per IP address? (what are problems with this?)
Any other suggestions???
You would do yourself one better by restricting the sign-ups to just a single IP address per user. This may not be good if you plan on having families all living under the same roof to have their own accounts, but in most cases this is practical.
Yes, restricting signups per IP is reasonable. I'd probably go with signups per rolling time period (say, a maximum of one new account in any one-hour period per IP). You might also flag suspicious signups (say, more than five per day per IP) for later followup.
You might also restrict users from voting until they've passed some hurdle, similar to SO's reputation system. Prevent poll voting until they've been a user for a week, have posted at least twice, have one friend request, etc.
I remember when I ran a online RPG I flagged when more than 5 or so accounts logged in with the same IP in the same day.
People mention the NAT issue. Read the header x-forwarded-for and compare that to the standard ip address.
If x-forwarded-for is present use this value. Most properly configured NAT routers will populate this field. The only ones that do not are typically anonymous proxies.
If you really are worried about people gaming the system, using a flash bit that uses sockets to connect, and provide say, session id, to the socket listener. You can then compare that with the ip address and x-forwarded for. If it does not match, they are behind an anonymous proxy. You could feel safe to not allow them to create accounts.
This works because most anonymous proxies out there aren't full Socks proxies where all network traffic goes through it, just HTTP. This worked very well for me in the past where we had a contest with voting and folks were using anonymous proxies to game the system.
Instead of limiting by account, you could set up limitations by email address. If users need to provide their email address, you already create one hurdle for them. Make sure they have to respond to a confirmation email to make sure the email address is real. Also keep track of email address and IP address, marking any count as suspicious where a single IP address has e.g. 5 or more email addresses. (In which case you could check those addresses to see if they are somehow related, like all from the same domain or similar names.)
Sure, people can create dozens of email addresses using GMail or Hotmail or even if they have their own private domain. But for many people this is already a bit too much. Basically, if you see 5 email addresses from gmail.com with the same IP address, it's suspicious.
One potential problem is if your users are behind a NAT such as a home router, ISP proxy, or corporate firewall. You will see the same IP for all of them.
Instead of blocking people I would simply record their IPs, create a report of duplicate IPs that you can run periodically to investigate suspicious activity.
In addition you can take a social approach, post the user's IP somewhere. This will provide a gentle warning and disincentive to people who fake accounts, as well as allow your community of users to potentially identify fakers.
I would recommend implementing a different authentication mechanism such as OpenID, or are Alex said, force the users to specify a valid email and send them confirmation links via email before accounts get created.
My preference is OpenID for sure.