I'm developing a simple Spring Boot RESTful API for poll management. In a few words, it's possible to create public polls and other "users" can vote for it.
Now I've to make sure that each client just votes once per poll. Because I want to prevent using common authentication mechanisms like HTTP Basic or JWT, I thought about authorizing by clients IP address. Means I store en entity like the following in database:
public class Vote {
private Long pollId;
private Long choiceId;
private String ipAddress;
...
}
Using something like such an approach, I prevent the need of authentication and account management.
Is this the right approach or are there better ones to ensure each client votes just once? Also how to deal with IP spoofing? Hope for any recommendations.
Is this the right approach or are there better ones to ensure each
client votes just once?
Not really. The idea that each computer has a unique IP address is only partially true.
In reality, people have more than one device (e.g. phone, computer at work, computer at home). And each device could be connected to a different network, with a unique IP in each one. Also, IP address change quite frequently. Disconnect your home modem/router for a couple of minutes and you're likely to get a new IP address when it reconnects. So one can change his home IP and vote again. Moreover, many (if not most) clients are behind NAT devices, which means that their IP is shared with many other users. Under the scheme you propose, once someone behind the same NAT as you votes, no one else can.
Lastly, users can easily use VPNs, TOR and various other techniques to basically vote as many times as they want.
Also how to deal with IP spoofing?
IP address spoofing is not trivial if one is using TCP. However, getting an actual IP address that's different from your current one is quite easy (VPNs, TOR, etc), and there's little you can do about it.
Related
I've tried searching for this but haven't really found a solution so decided to post a question.
I'm working on an application where a user will input an IP (an SNMP device) and my application needs to connect to it and work with it. During runtime of the application, the user may provide another IP address and then I need to connect to the second one also keeping both the connections alive (as singletons).
My problem is I'm not able to wrap my head around this conceptually. My connection module is right now something like the following:
#Override
Configure() {
String ip = first ip;
}
#Provides
Connect connect() {
// connect to ip
return connection;
}
Can anyone give me some hints here?
You should probably pass the IP address as an argument for your Connect class constructor. You can then look at FactoryModuleBuilder so that you can inject dependencies to your Connect class in your code. As for your requirement about singletons, I am not too sure of what you mean there. A singleton means, by definition, that there's only one instance of a class. Here, you want two (or possibly more). What I suspect is that you want at most a single Connect instance per IP String in the entire application. If that is the case, your factory needs to be a bit cleverer that the one created automatically by FactoryModuleBuilder. It could be a singleton itself and store an index (map? concurrent map? cache? It depends on your thread-safety requirements) of ip -> connect instances for those that have been already created.
Hope it helps.
I need to send email notification to web site subscribers. All subscribers receive simply the same thing. I can create a for loop and send one email per user, which is not very efficient as the same thing is being copied from the app to email server every time. On the other hand, I can set multiple receivers in in the "to" field. This is not good as I don't want to expose the emails to all receivers. So, is there an option to send a single email to all users and hide the receivers from each other?
Sending each email individually may be inefficient, but it is not like you have to carry each email by hand to the mail server, so it should not be a problem. If you already have it working, I would suggest that you leave it as it is. Especially since this method has an advantage which I will show further down.
If you really feel like spending time to optimize things, you can place recipients of the message in the Bcc: field. This means that they will not see each others' address. (The mail server will make sure they don't.)
There are two problems with Bcc:
Most mail servers impose a limit on how many people you may Bcc:, and it is not like they advertise what this limit is, so you might end up having to discover it yourself with trial and error, possibly accidentally spamming some people in the process.
Most mail servers will still require you to put some recipient in the To: field, regardless of who you put in Bcc:, and then the problem is that people are going to be receiving emails addressed to some unknown-to-them address, like the "undisclosed-recipients" receiver of mailing lists of old. And anti-spam filters tend to dislike this kind of recipient.
Sending each email individually allows you to address each email to its proper intended recipient. Email nowadays is plagued by spam and spam filters, so it is best to not take chances with it.
I have a general question about a best practice or pattern to solve a problem.
Consider that you have three programs running on seperate JVMs: Server, Client1 and Client2.
All three processes make changes to an object. When the object is changed in either client, the change in the object (not the new object) must be sent to the server. It is not possible just to send the new object from the client to the server because both clients might update the object at the same time, so we need the delta, and not the result.
I'm not so worried about reflecting changes on the server back to the clients at this point, but lets consider that a bonus question.
What would be the best practice for implementing this with X amount of processes and Y amount of object classes that may be changed?
The best way i can think of is consistently using the Command pattern to change the object on the client and the server at the same time, but there has to be a better way?
One of the possible ways to solve that is the Remote Method Invocation system in Java. Keep all the data values on the Server, then have the clients use remote calls to query them.
This would however require some smart caching to reduce the amount of pointless calls. In the end you would end up with something similar to the Command Pattern.
Modern games try to solve this issue with something I'd call an Execute-Then-Verify pattern, where every client has a local copy of the game world, that allows him to come to the same conclusion for each action as the server would. So actions of the player are applied to the local copy of the game world assuming that they are correct, then they are sent to the server, which is the ultimate instance to either accept that or revoke it later on.
The benefit of this variant of local caching is, that most players do not experience much lag, however in the case of contradictory actions they might experience the well-known roll-backs.
In the end it very much depends on what you are trying to do and what is more important for you: control over actions or client action flow.
I'm hoping not to re-invent the wheel -- I'm fairly new to Java, but I need a simple but robust algorithm/code/software to perform email verification for users of a web application (e.g. I only need help with step 4 below). That is, I need to verify the user logging in has access to the email address he/she provides during log in.
The steps I have in mind for the Java middle-tier would be:
Java POJO receives user's email and password from client.
The POJO talks to a database server to verify the email/password combo is valid.
If valid, the POJO sends an email to the email address, asking user to reply to email (or click on some provided link, etc.)
The POJO receives notification (how?) that the user has replied to email (or clicked on link, etc.).
The POJO informs the web-application of success (or failure) of authentication, thereby permitting or denying access to the application.
I can write everything except step 4. Essentially I need a way to send an email to a user and then receive some type of response indicating the user received the email.
Anyone know how this can be accomplished? If not, what do you recommend as the next best/simplest solution?
I'm not using a framework as my Java middle tier is very simple. I'd like to keep the solution lean (meaning, don't want to install/implement more than I need; Spring seems overkill). I read up Shiro, but didn't find any evidence it supports email authentication. Any advice is much appreciated to help me avoid writing unnecessary/unproven routines.
The easiest way is to have some code that connects to the mailbox of the destination address, using either POP3 or IMAP, and waits for new, incoming messages.
When you send the email, you can add a Message-ID header. When the user replies to the email, there will be a References that should have the Message-ID that the user is replying too.
When you can use this ID to correlate what they are responding to.
For safety, you may wish to embed the ID within the message itself (since most folks today don't edit replies), so you can look through the body of the message if for some reason the Reference header isn't supplied. There are other techniques that let you give each mail a customer Reply-To address, that's another way this can be done, but that requires some mail server support.
But, anyway, once you have the message structure figured out, you simply listen to the inbox of the address, and look for new messages. As they arrive, your strip the Message IDs, and flag them as appropriate in the DB, or whatever.
As for "waiting" for the message, you must appreciate that it can be a long wait. Rather than having a POJO waiting for it, rather have a simple process that pings the status. You can have a timer that fires every second, and then checks the database to see if it's been updated, etc. Obviously, this is something you want to be able to cancel.
For all of the mail needs, you can use JavaMail -- it does all this, and it pretty straightforward to use.
there are two controllers involved (two POJOs).
the first connection, for steps 1,2+3 talks to one object in the server. as part of (2) a unique code (the UUID mentioned in comments)is generated and saved to the database.
the second connection, when the user clicks on the link, goes to another controller (another POJO, which could be the same class, or could be a different class, depending on your implementation). that reads the UUID from the link, goes to the database, finds the email associated with the UUID, and marks the email as verified.
update i'm struggling to see what you are missing, but when the user clicks on a link in an email the operating system opens a web browser. the web browser makes a connection to the server. the server receives the HTTP GET request with the UUID in the URL and passes the UUID to the POJO.
some more terms: the process of handling the incoming request in the webserver is typically called "routing" and the general pattern used to structure the code that is called is "MVC". exact details will depend on the application framework you are using. for servlet-based java code there's a mapping from URLs to servlets (servlets are java code implementing a certain interface - a framework might provide the servlet which ultimately invokes what you are calling a POJO, or you might write the servlet yourself, in which case that would be your POJO, although in that case it's a misnomer since it implements a specific interface) in the web.xml file.
also, i guess, the web browser on the client uses TCP to make a connection across the network (almost always this is on top of a protocol called IP because you are using the internet). on top of this, the client "speaks" messages in HTTP. all these different layers are described in the "7 layer osi network model".
there's a huge amount of detail on so many levels. hope that gets you started.
see also http://www.quora.com/What-happens-when-you-type-a-URL-into-your-browser
I have created a simple Java chat program, which provides one server and multiple clients.
But I only can make it where all clients can talk (the messages was sent to all clients).
I need to make a private chat beside the public chat I've made.
E.g: computerA just wants to chat with computerB, but computerA still can talk with all clients. How can I do this?
The easiest way to do it is to modify your protocol a little bit to include some information whether the message you are sending is a public (everyone can see it) or a private one (just user A and user B talking).
With that information in hand, in the server, whenever you find a private message, just send it to the one and only destination expecting that message. Do not try to do some peer to peer stuff because you will encounter many problems along the way.
Other small variation of this solution would be supporting "private rooms" on your chat server. But that will be a little bit more complicated to implement.