Re: eppc -> "Remote Access Not Allowed"?
Re: eppc -> "Remote Access Not Allowed"?
- Subject: Re: eppc -> "Remote Access Not Allowed"?
- From: Graff <email@hidden>
- Date: Fri, 11 Jun 2004 23:16:02 -0400
On Jun 11, 2004, at 6:29 PM, Sander Tekelenburg wrote:
At 14:53 -0400 UTC, on 2004-06-11, Graff wrote:
On Jun 11, 2004, at 11:05 AM, Sander Tekelenburg wrote:
[...]
For some reason the eppc scheme chokes when the
passphrase contains a hash ("#") character. Tsssk...
[...]
You probably need to URL-encode the password since it is being passed
by way of a URL:
<http://www.blooberry.com/indexdot/html/topics/urlencoding.htm>
Replace the hash (#) character with # and see if it works.
Indeed it does. Duh. Should've thought of that myself. Thanks! :)
[...]
This is not unique to the eppc scheme, it will probably occur with all
URLs. It most likely has nothing directly to do with Apple or
AppleScript.
Well, it most certainly has something to do with Apple, because when
you
don't specify the username/passphrase in the URL, you get a dialog
that asks
for that. That dialog happily accepts a hash and then happily chokes
on it.
I can understand I'd need to encode this when providing the passphrase
inside
the eppc URL in the script. But you don't always want to store
passphrases in
scripts. It's often a security risk to do so. And for scripts that
need to
work for different users, it's not even an option.
It seems unreasonable to me to expect users to type encoded
passphrases into
pretty dialogs. The system should be smart enough to know that a hash
needs
to be encoded and do just that. A hash in a passphrase doesn't give any
problems when using ssh or afp, so why should it be a problem with
eppc?
I didn't know that there was also a problem when the password is
entered through the password dialog that comes up by default. That
certainly should be smart enough to figure out how to properly encode
the password behind the scenes. I'd bug it, that part does sound like
buggy behavior to me.
As a workaround you can use your own dialog to get the password, encode
it, and then build the URL using the properly encoded password. The
only downfall is that the password will appear while the user is typing
it, there are no password text fields available to plain vanilla
AppleScript. However, I do believe that there are some OSAX out there
that do provide a proper password dialog.
Here is a set of subroutines from Apple that do URL encoding:
----
-- these subroutines were taken from
-- a script on this Apple web page:
-- <
http://www.apple.com/applescript/scripteditor/12.html>
-- this sub-routine is used to encode text
on encode_text(this_text)
set the acceptable_characters to
"abcdefghijklmnopqrstuvwxyz0123456789_"
set the encoded_text to ""
set the character_list to {}
repeat with this_char in this_text
set this_char to the contents of this_char
if this_char is in the acceptable_characters then
set the end of the character_list to this_char
else
set the end of the character_list to encode_char(this_char)
end if
end repeat
return (the character_list) as string
end encode_text
-- this sub-routine is used to encode a character
on encode_char(this_char)
set the ASCII_num to (the ASCII number this_char)
set the hex_list to {"0", "1", "2", "3", "4", "5", "6", "7", "8", "9",
"A", "B", "C", "D", "E", "F"}
set x to item ((ASCII_num div 16) + 1) of the hex_list
set y to item ((ASCII_num mod 16) + 1) of the hex_list
return ("%" & x & y) as string
end encode_char
----
- Ken
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.