I am making a chat program in Java. When a user sends a message to the server, the server sends that message to every other user. The problem is, when a user is typing, he can receive a message, that will be written in the middle of the text he is typing.
A user must always be able to receive messages, while at the same time being able to write without having text appearing in the message he is typing.
Is there any way to do this in Java? A good solution would be to have a part of the console where the messages appear, and another one solely for typing.
It seems that there are libraries similar to ncurses, but are there any solution that doesn't rely on external libraries?
Cleaning the console using ANSI escape codes doesn't help since the text an user is typing might simply disappear because of it.
You can create 2 seperate console applications (one which reads, and one which only sends). That way your console windows would be separate and text would not conflict. Bear in mind that if you are using sessions, you would need to bind both sessions to the same user.
Another solution could be reading and storing each individual key without pressing enter. When you receive the response from the other client, you manually clear everything, print the text received, then place whatever the user was typing directly after.
Both of the above solutions seem hacky, and I feel Swing or JavaFX would be the way to go.
Related
Currently I have an applet which is used to process an input (a url provided by the user) but since this is the only interaction with the user I would rather not force them to download the entire app. Preferably I want no extra downloading at all.
Is it possible to have let the user enter a url into an html form and then send that input to be processed server-side and then the output is sent back to the user?
I have considered making a tiny applet which takes the url as an input and then calls a server-side library to process it. Still not my ideal solution. Would this actually work?
What I really want it a jar to be called when the user enters form data. Please help
Is it possible to have let the user enter a url into an html form and
then send that input to be processed server-side and then the output
is sent back to the user?
Yes absolutely. Use JavaScript in the browser to send this to a Java back-end. This is how something like this is normally done, not via an Applet.
Why am I trying to do this?
Right now I'm trying to make a multi tabbed SSH client for use with a few servers. I have 8 at the moment, soon to be 9. As you can imagine, there are a few redundant tasks one has to do when working with Linux. Connecting to each server to make changes one at a time is a terribly tedious process. That's why I'm trying to make an SSH client that can connect to multiple servers at the same time so I can send a command ONCE to have it affect all servers I own.
How far am I right now?
I have a nice UI set up that can connect, log-in, and receive data from the servers. For input, the API requires I specify an inputstream. If I specify System.in as my inputstream, I can then run the program, and have whatever I type into console be broadcast out to the different servers, via the API.
The problem
is that no end user will ever want to work with a separate console to use this program. It will look dinky. So I need some way to take input from the text field to send it through a specified inputstream. That means I'll need an inputstream that never closes unless the program closes. Like System.in. Also, I can't easily redefine the stream once I set it. I searched for an answer yesterday for around 10 hours. Couldn't find anything. If anyone can help, please do. Thank you.
I need
an inputstream that works exactly like an outputstream. It stays open even when nothing is being sent through it, but as soon as it gets data, the data is sent automatically to anything that is using it. This API is very strange, but this last inputstream part is the only thing keeping me from finishing up my program. Thank you for your time.
JSCH sudo su command "tty" error
I was using the API incorrectly. Stupid, yes. I don't want anyone else making the same mistake though. I guess I was following a bad example found somewhere else on the internet.
Essentially, you don't even need to set the input stream. You just need to use the output stream that already exists. Write directly to the output stream. Pretty sure I was trying to do this at 3am last night. It was right in front of me the whole time.
I am really unsure as to where I should be posting this, but if this is the wrong place could someone direct me where to I could get an answer? I want to be able to send commands to my email address, and have the commands parsed and executed when the message is sent. I.e. I send an email and it contains this:
public class sentThruEmail {
public static void main(String[] args) {
System.out.println("Hello");
}
}
I would want to configure my program to recognize when a new email comes from a sent address, to open it, compile it (in this case compile the java) and then execute it on the machine that the program is running on.
How can I go about figuring out how to do this? Any help would be wonderful, thanks!
EDIT: Or maybe the first step would be how to recognize an email was received from an address at all? In Java, how could I go about that: recognizing that an email was received and outputting something to the screen to alert the fact.
This would be a very bad idea. Blindly accepting email from an untrusted source, compiling it, and executing it is an enormous security hole.
There are several parts of this to consider:
Security
As others mention, there are security risks to consider, here. If that worries you (and it should!), you may want to consider some of the following:
Digitally signing these "command" emails, and verifying that signature before looking at the email
PGP is a popular choice for this
Running your program (which reads the emails) in a "sandbox" environment, such as being chroot'ed or in a jail
Only run a very limited set of commands - perhaps just ones you invent.
Getting Mail
If you still want to do this, given the security issues, you will need your program to read mail.
You probably want to use IMAP for this, or POP.
Parsing
Once you have the mail, you need to parse the contents.
You could just compile it directly if you are only sending code.
You could also send the code as an attachment with a certain MIME type to identify it. That way you could still send a 'normal' email (perhaps with commentary about what this code is for), but your program would be able to cleanly separate out the code.
Responding
How will you communicate results back? Or do you care?
You may want to send a reply email (use SMTP), or update a webpage. A webpage is nice since if you are running the web server locally, you can just write a file directly.
Examples
The standard "confirmation email" system has a lot of similarity to what you describe. Someone sends an email to an automated system, it reads it, does some processing, and replies. Search around for those systems and I'm sure you'll get started.
I created the Exquisite Corpse Emailer project, which does much of what you describe (but in Perl). It only accepts a very small set of limited commands, but it listens to an email address on IMAP, parses the text, updates a database as a result, etc.
But if you want to do it, look into sockets programming, as you would need to connect to your email provider (if he allows terminal login)
I have an existing swing desktop application that I wish to convert to a web application. The first thing that is stopping from doing so is that the desktop application deals with writing and reading from PDF files. Also the user fills up the PDF forms which needs to be read by the application.
Now a typical use case in the desktop application is like, the user logs in opens a PDF form and fills it up. The swing application manages where the file is stored so it goes to the file and reads the form, extracts the data and stores the data in the db. The user might not fill up the form all in one go. He might save it come back to it later and continue.
All of this needs to be done by the web app now. My problem is I don't want the user to download and upload the form multiple times to the server. That would eat the bandwidth and also asking the use to save the file locally and upload it back once he completes filling the form doesn't appeal to me since the desktop application nicely used to manage the location of these files as well.
Would I need to implement something like a dropbox kind of thing? A small deamon running continuously to check what file has been updated and upload it to the server? That would be difficult since at the server I wouldn't know if the file was latest or not. Is there anything like this that someone might have done before?
I have anther suggestion: why don't you show the user a form with the same fields and transfer them to the PDF after the user submits. This way the Pdf does not leave the server and you transmit just the minimal amount of data.
Switching to a web-version of the application may force you to re-think some of the way you are doing things. Certainly browsers are intentionally limited in their access to the local file system which introduces a major hurdle for your current mode of operation.
Even if you could display the PDF within a browser, detect the completion of edits and send this back to the server from within browser code (which is probably possible), you'll be subject to different browsers doing different (strange) things with whatever pdf plugin is installed.
As Vitaliy mentioned already, switching being able to populate a (web) form in the browser means that whole download upload problem goes away. But then you have to take what the user has done in a web page and pump that into a PDF somehow. If you don't HAVE to start with a PDF, but could collect the data and produce a PDF at the end then you might have more options. For example you could use iText to create a PDF directly if you don't have too many styles of document to work with. You could use something like Docmosis which you can give templates to and get it to populate and render PDFs later. With the Docmosis option you can also ask Docmosis for the list of fields in the template so could build a web form based on the selected template, let the user fill it in, then push that data to Docmosis to produce the file.
Hopefully there's some options there that are useful to you.
Adobe documents how to do this here. Never underestimate the power of design-by-google. I know this can be made to work because I've used PDF forms on line.
I worked on a similar issue a few years ago, although I wasn't dealing with signed forms. The signature definitely makes it a little more difficult. However, I was able to use iText to create a PDF form with fields, and only submit the field data back to the server. Offhand, I unfortunately do not remember exactly what/how we did it, but can confirm it is doable (with limitations/caveats). Ex: User had to have PDF reader plugin installed & User was forced to d/l the pdf every time.
Basically what I did was use iText to create an FDF from a PDF (with form existing form fields). The submit button in the FDF actually submits the form data to a URL of your choosing (not unlike an HTML form). Once you have that data, I believe I merged the form fields (from the FDF) with the PDF on the server side using iText.
Once you use the server to maintain all the form data, the synchronization/locking process you use to ensure that a single user is updating the latest and greatest form data is up to you.
Your comment under jowierun indicates that you want to deal with word/excel/etc docs as well, so I am not entirely sure I am understanding your needs. Your initial post discussed the needs to fill out PDF forms locally, but afterwards it sounds like you are looking for a file-sharing system instead.
Can you please clarify exactly what you are trying to accomplish?
I am working on a project in NLP requiring me to download quite a few video game reviews --- about 10,000 per website. So, I am going to write a program that goes to each URL and pulls out the review part of each page as well as some additional metadata.
I'm using Java and was planning on just opening an HttpURLConnection and reading the text through an input stream. Then, closing the connection and opening the next one.
My questions are this:
1) Let's assume this is a site with medium-to-small amounts of traffic: normally, they receive about 1000 requests per second from normal users. Is it possible that my program would cause undue stress to their system, impacting the user experience for others?
2) Could these connections made one right after another appear as some kind of malicious attack?
Am I being paranoid, or is this an issue? Is there a better way to go about getting this data? I am going to several websites so working individually with site administrators is inconvenient and probably impossible.
If you mimic a web browser, and extract text at human speeds (that is, it normally takes a human several seconds to "click thru" to the next page even if they aren't reading the text), then the server can't really tell what the client is.
In other words, just throttle your slurping to 1 page per few seconds, and no problems.
The other concern you ought to have is legality. I assume these reviews are material that you didn't write, and have no permission to create derivative works from. If you are just slurping them for personal use, then its ok. If you are slurping them to create something (a derivative work), then you are breaking copyright.
I believe you are misunderstanding how HTTP requests work. You ask for a page and you get it... the fact that you're reading a stream one line at a time has no bearing on the HTTP request and the site is perfectly happy to give you your 1 page at a time. It won't look malicious (cause it's just 1 users reading pages... totally normal behavior). You're 100% ok to proceed with your plan (if it is as you described it).