 |
| Welcome
Sign Up Log On |
|
|
Messages: (12) 1
UserLand released a new beta of Frontier and Radio. Both support Simple Cross-Network Scripting.
SCNS was promised years ago, but since then a number of us had almost given up on it. Some things, though, are worth waiting for.
The basic idea is that I can run a command in a scripting environment on another machine as simply as I can on my own. (That assumes that the other machine supports it, of course, and that I have permission.)
For example, if I want to know the email addresses of everybody on the TruerWords mailing list, I can go to the server and run a short script which will prouduce that information for me. I could then make that script available for calling over the network, via xml-rpc. The next time I wanted that list, I wouldn't have to go to the server to get it, I could request it from my workstation.
Still, calling it from my workstation involved a multi-line script to build the paramters table, pass the params in the right format, etc., etc. Now it's as simple as running it on the server. Let's compare. Here's the call I'd make if I was standing at the server:
email.getSubscribers( "truerwords", "truerwords" )
(Since that example assumes that I'm standing at the server, I don't need to include my own username and password.)
Here's what the same call could look like, now, from my workstation:
["xmlrpc://www.truerwords.net/RPC2"].email.getSubscribers( "truerwords",
"truerwords", "seth@macrobyte.net", "my password" )
This doesn't make anything possible that was previously impossible, but it does wonders for simplifying network-based code. I'm glad they finally shipped it.
[Top]
[Top]
On 2/8/02, Clark Venable said:
>Is there a way to keep the xmlrpc call (which includes a password) >from prying eyes? Can it be tunneled somehow?
Well, I'm not sure who would see the call.
In radio, this is a script that would be sitting on your machine, and would be run before the page is uplaoded to the "cloud" or wherever your site lives. The result of the script would be in the web page, not the script itself: in other words, nobody sees your password.
In fact, the only time I think anybody would see the password is when you're intentionally sharing copies of your script. In that case, you have to be careful to remove your password before sharing the script with anyone... but that's true whenever you share a script.
It's possible that I don't understand the specific situation you're thinking about. :-)
Seth
[Top]
[Top]
On 2/8/02, Clark Venable said:
>>In radio, this is a script that would be sitting on your machine, and
>>would be run before the page is uplaoded to the "cloud" or wherever
>>your site lives. The result of the script would be in the web page,
>>not the script itself: in other words, nobody sees your password.
>
>But before your workstation can render the page with the included
>script result (not the script), doesn't the workstation have to
>communicate with the server to get the result, and isn't that password
>sent in the clear?
Yes, but I didn't realize you were talking about that sort of thing.
There are solutions to that, including use of https instead of http (ssl, the same technology used for secure web pages), and there are probably other things I'm not thinking about right now.
Nothing that's currently built into Frontier.
Just keep in mind that this problem isn't specific to "Simple Cross-Network Scripting". It's the same for most everything else you do on the net, including ftp files to an unsecure server, or manage your radio blog in the cloud.
>>In fact, the only time I think anybody would see the password is when
>>you're intentionally sharing copies of your script. In that case, you
>>have to be careful to remove your password before sharing the script
>>with anyone... but that's true whenever you share a script.
>>
>>It's possible that I don't understand the specific situation you're
>>thinking about. :-)
>
>What I'm thinking of is that in health care, privacy regulations are
>coming online soon that are very specific with regards to encryptions
>of patient information (that's the extent of my understanding).
Actually, because of one of Macrobyte's customers, I'm very familiar with those new requirements.
SSL (or https) is the answer to that problem. You need encrypted communications. Frontier doesn't support it natively, but I know about a DLL that's been written which makes it possible, and this would also make it possible to do an encrypted form of xmlrpc.
That DLL isn't currently available for public consumption, but it proves that it can be done.
Seth
[Top]
[Top]
[Top]
On 2/8/02, Brian Andresen said:
>Ah, it's clear that you haven't spent much time using a packet >sniffer. :-)
True. Like, none.
I didn't realize he was talking about end-to-end password security until his second message.
>Now that you've got yourself a Unix-based OS, go get ethereal and look >at what's traveling on your network. And on every network connecting >you to the server on the other end.
Get the behind me, Brian. I don't have time for any more cool toys right now.
Oh, man, too late... the tempter wins again.
>Obviously this isn't as much of an issue if you're doing local RPC, >between machines on your own LAN. But in the general case, you'll >have cleartext passwords heading out through the net.
I knew that, of course, but I thought he was talking about people seeing the password in his source. He asked about keeping the xmlrpc call from prying eyes... that could refer to the call as it's written in the source, or it could refer to the call over the network.
>It's not XML-RPC's job -- at least not the way Dave has cast it so far >-- to handle this aspect of authentication and security. I think that >could be a good thing, because it leaves room for standards like TLS >(Transport Layer Security, formerly known as SSL -- see >http://www.ietf.org/html.charters/tls-charter.html). If only Frontier >supported it...
XML-RPC itself can be used in any number of transport protocols. I know it's been run over SMTP.
You can run it over https (TLS, or SSL, whatever) now, if you shut off Frontier's server and put it behind IIS or SSL. Then you'd just need that DLL in your client copy of Frontier to have end-to-end encryption.
Seth
[Top]
[Top]
[Top]
[Top]
Yes, my crypto extension does symmetric RC4 encryption. It's not really new though because the functionality has been available previously in a UCMD by Leonard Rosenthol.
Note that by simply encrypting the password, you don't really gain anything in security. Somebody listening in on the connection could just grab the encrypted password and put it in his own requests without decrypting it. If secure authentication is your only concern, take a look at HTTP digest authentication (rfc2617). It's implemented in Frontier (see mainResponder.security.httpAuthentication) but not in Radio, AFAIK.
I agree with Greg that security should be a function of the transport. After publishing the crypto extension, I actually got several requests for an SLL extension for Frontier.
[Top]
<- Previous Thread:
Another Baby!?
Next Thread: ->
Rambling on Life, Frogs, Knitting, and New Babies
Until August 31
My Amazon sales
benefit the PMC
Apr 1 - Aug 31
Ad revenue
benefits the PMC
|
TruerWords
is Seth Dillingham's personal web site. More than the sum of my parts. |
