SOAP bypasses security on the client-side. The host running the SOAP server knows the inherent risks. The same as running any network available service. What soap does is run a server process on the client's machine that attempts to bypass any firewall as well as allowing executable code to be run on the client.
A request for a page produced by a CGI script is plain text. The CGI server runs a local, trusted application that outputs a plain HTTP text stream that is sent to the client that requested it (usually a web browser) and is not interpretted (except by javascript or a browser plugin)
SOAP implements the equivalent of allowing a remote host to send executable code to the client over a connection that is expecting plain text. It is the equivalent of having Outlook with VB Macros enabled that automatically executes as soon as an email is *received*. The biggest difference is that it is port 80 instead of 25. You will rely completely on the application itself to enforce whatever security restrictions.
Chances are that some SOAP applications will be browser plugins. But this is an opportunity for every SOAP service provider to lock you in to their proprietary interpreter, displayer, whatever; and believe me, they will.
port numbers are a *convention* that makes filtering easier. If the large majority of messages over each port are benign (or at least known) -- then it makes it easier to handle the exceptions. If you know that HTTP requests over port 80 are going to be handled statically most of the time then it is safer to accept them. But if the relative security of a port is compromised, then it becomes harder to spot portential threats.
The same principle, in reverse, is why phil zimmerman (and others) advocates email encryption. The more common encryption is, the less strong the protocol needs to be to achieve relative security. It takes more work to filter thorough a million 46 bit ciphertexts than 1 128 bit. Technically this isn't true, but practically it is.
It is easier to spot a smoking gun if there are only two people in the room than if you are in a stadium full of people.
bring your jacket liner to work. or use google. Your company doesn't need to buy more hardware and hire more techs just so you can remember which track is "Hit Me Baby One More Time"
exception handling is easier in omni's way, but probly not enough to justify the programming overhead. But a message loop is more graceful and more flexible from an OO perspective too. Think about the other latency case -- user interface.
while (response = network_event_handler(request) == NULL)
{
wait();
if (timeout())
{
exception("Time to find out who's running Gnutella");
}
}
you need to look at the other side of the issue. Maybe the admin doesn't want the users running your program through his network. I'll admit there a lot of ignorant bone-headed admins out there, but chances are their network is insecure already, so soap doesn't matter to them one way or another.
So you are willing to demolish the TCP/IP protocol to spite a few paranoid admins.
If you are developing an application that Company X needs to use and it has to communicate through the firewall, a simple phone call to PA's manager would solve the problem. But the real reason you want to run SOAP on port 80 is because you don't have a legitimate reason for your application to be running inside the corporate firewall. By legitimate, I mean in the minds of management. No, a "harmless" "e-commerce" "web-app" for music/pr0n/gambling/shopping/whatever is not likely to be considered a legitimate reason.
Any admin would much rather have a program using port 12345, because then, if there is an exploit or malevolent user, it can be blocked at the packet level, instead of putting together every response and parsing the entire message using an infinite symbol list and AI that can detect the potential threat in any file sent through the only port on the only address on the only host in the network, if you can call it that anymore.
SOAP was developed specifically so companies (such as Microsoft) can execute arbitrary code through otherwise secure firewalls where all they have to do is get the user to download a simple client program that wraps the commands in an XML format and sends it as an innocent looking HTTP response. It was designed to *solve* the problem of corporate users wanting to run network applications that are verboten or otherwize blocked by their network administrators.
SOAP is designed with security in mind. Security circumvention.
how do you get decent responsiveness out of nedit (without upping the hardware)? I've tried it in TWM on a K6-II 333 w/64 memory and it is too slow for me. Granted, its no 100% True Java(TM)IDE Glacier but its not much better than mozilla, which at least can print characters as fast as I can type?
have you ever heard of CVS? or a filesystem? Or a windowing system?
I can't think of any large scale project that needs an IDE. IDEs are designed for simple projects and inexperienced programmers. When a project reaches a certain complexity, you'll start customizing tools anyway, and the IDE just gets in the way. Most Java devs I know use vi, and only install JBuilder to keep management happy.
EditPlus is my favorite simple text editor too. But does anyone know a way to get it to do save remote using scp/ssh (instead of ftp) or use cvs checkins?
I don't need vi or emacs, alt+tab and ctrl+shift+arrow works fine for me.
If the code red problem was primarily caused by home users on broadband, then why did it go away so quietly? You know 90% of the people out there couldn't possibly have downloaded the patch or turned off the personal web server that came with front page 98.
what happens if your windowing toolkit doesn't support all the widgets? So you don't have motif (shudder) or win95 pr gtk (hopefully) -- one nice thing about awt is you can use an applet on crusty old systems. Of course, applets should have access to at least a good part of the HTML DOM anyway.
Slashdot Mirror
I am not running any CGI scripts to view slashdot. All I receive is HTML. I am not at risk from requesting a CGI script.
SOAP bypasses security on the client-side. The host running the SOAP server knows the inherent risks. The same as running any network available service. What soap does is run a server process on the client's machine that attempts to bypass any firewall as well as allowing executable code to be run on the client.
except that if we can use port filtering primarily, it reduces the amount of work by orders of magnitude
A request for a page produced by a CGI script is plain text. The CGI server runs a local, trusted application that outputs a plain HTTP text stream that is sent to the client that requested it (usually a web browser) and is not interpretted (except by javascript or a browser plugin)
SOAP implements the equivalent of allowing a remote host to send executable code to the client over a connection that is expecting plain text. It is the equivalent of having Outlook with VB Macros enabled that automatically executes as soon as an email is *received*. The biggest difference is that it is port 80 instead of 25. You will rely completely on the application itself to enforce whatever security restrictions.
Chances are that some SOAP applications will be browser plugins. But this is an opportunity for every SOAP service provider to lock you in to their proprietary interpreter, displayer, whatever; and believe me, they will.
its naive to use weak passwords, but that doesn't mean that we need microsoft or some other company to DOS your system tryping to crack them.
host address and protocol?
port numbers are a *convention* that makes filtering easier. If the large majority of messages over each port are benign (or at least known) -- then it makes it easier to handle the exceptions. If you know that HTTP requests over port 80 are going to be handled statically most of the time then it is safer to accept them. But if the relative security of a port is compromised, then it becomes harder to spot portential threats.
The same principle, in reverse, is why phil zimmerman (and others) advocates email encryption. The more common encryption is, the less strong the protocol needs to be to achieve relative security. It takes more work to filter thorough a million 46 bit ciphertexts than 1 128 bit. Technically this isn't true, but practically it is.
It is easier to spot a smoking gun if there are only two people in the room than if you are in a stadium full of people.
bring your jacket liner to work. or use google. Your company doesn't need to buy more hardware and hire more techs just so you can remember which track is "Hit Me Baby One More Time"
if you're already burning a "few more CPU cycles" to assemble, parse, analyze, and resend all your packets, what's a few more to brute force decrypt?
exception handling is easier in omni's way, but probly not enough to justify the programming overhead. But a message loop is more graceful and more flexible from an OO perspective too. Think about the other latency case -- user interface.
while (response = network_event_handler(request) == NULL)
{
wait();
if (timeout())
{
exception("Time to find out who's running Gnutella");
}
}
you need to look at the other side of the issue. Maybe the admin doesn't want the users running your program through his network. I'll admit there a lot of ignorant bone-headed admins out there, but chances are their network is insecure already, so soap doesn't matter to them one way or another.
So you are willing to demolish the TCP/IP protocol to spite a few paranoid admins.
If you are developing an application that Company X needs to use and it has to communicate through the firewall, a simple phone call to PA's manager would solve the problem. But the real reason you want to run SOAP on port 80 is because you don't have a legitimate reason for your application to be running inside the corporate firewall. By legitimate, I mean in the minds of management. No, a "harmless" "e-commerce" "web-app" for music/pr0n/gambling/shopping/whatever is not likely to be considered a legitimate reason.
Any admin would much rather have a program using port 12345, because then, if there is an exploit or malevolent user, it can be blocked at the packet level, instead of putting together every response and parsing the entire message using an infinite symbol list and AI that can detect the potential threat in any file sent through the only port on the only address on the only host in the network, if you can call it that anymore.
SOAP was developed specifically so companies (such as Microsoft) can execute arbitrary code through otherwise secure firewalls where all they have to do is get the user to download a simple client program that wraps the commands in an XML format and sends it as an innocent looking HTTP response. It was designed to *solve* the problem of corporate users wanting to run network applications that are verboten or otherwize blocked by their network administrators.
SOAP is designed with security in mind. Security circumvention.
fraud
pseudocode is better than UML -- especially my favorite blend of bash, c, c++, perl, and pl/sql.
/*find out what to return later*/
/* etc. */
and if you code on a framework like below you can never go wrong.
typedef int ret_val
ret_val do_something ()
{
step_1() { printf("this will do the first step"); }
step_2() { printf("this will do the second step"); }
}
int main ()
{
do_something();
exit(0)
};
can't you use ctags for this?
So your theory is that no tool is useful unless it is the best choice for everything? What do you progam in, then?
You answered your own question... C -- of course
(just kidding)
wouldn't it be nice if you didn't have to expand it (at least not right away) -- there are only so many columns on a 1600x1200 display at 6dpi
grep helps with that memory problem
how do you get decent responsiveness out of nedit (without upping the hardware)? I've tried it in TWM on a K6-II 333 w/64 memory and it is too slow for me. Granted, its no 100% True Java(TM)IDE Glacier but its not much better than mozilla, which at least can print characters as fast as I can type?
have you ever heard of CVS? or a filesystem? Or a windowing system?
I can't think of any large scale project that needs an IDE. IDEs are designed for simple projects and inexperienced programmers. When a project reaches a certain complexity, you'll start customizing tools anyway, and the IDE just gets in the way. Most Java devs I know use vi, and only install JBuilder to keep management happy.
EditPlus is my favorite simple text editor too. But does anyone know a way to get it to do save remote using scp/ssh (instead of ftp) or use cvs checkins?
I don't need vi or emacs, alt+tab and ctrl+shift+arrow works fine for me.
If the code red problem was primarily caused by home users on broadband, then why did it go away so quietly? You know 90% of the people out there couldn't possibly have downloaded the patch or turned off the personal web server that came with front page 98.
what happens if your windowing toolkit doesn't support all the widgets? So you don't have motif (shudder) or win95 pr gtk (hopefully) -- one nice thing about awt is you can use an applet on crusty old systems. Of course, applets should have access to at least a good part of the HTML DOM anyway.
go buy windows xp and tell me the price of internet explorer didnt go up