1,633
edits
Talk:UDP API DEV: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
Epoximator (talk | contribs) No edit summary |
mNo edit summary |
||
| Line 1: | Line 1: | ||
{{TOCright}} | |||
== Encryption == | == Encryption == | ||
"encryption pass must be set in profile settings on the website" | "encryption pass must be set in profile settings on the website" | ||
for this to be really useful for all the paranoid ppl out there, you should really change the website to https. luckily for me, I'm not paranoid about this, but I thought it should be pointed out. --[[User:Suppy|Suppy]] 06:41, 27 January 2006 (CET) | for this to be really useful for all the paranoid ppl out there, you should really change the website to https. luckily for me, I'm not paranoid about this, but I thought it should be pointed out. --[[User:Suppy|Suppy]] 06:41, 27 January 2006 (CET) | ||
: https is | : https is considered a possible performance issue and is therefore currently not supported by AniDB. if I have too much time I might write something up which allows only the signup, login and profile pages to be transmitted via https and everything else via http. does anyone know if there is a good howto somewhere on how to best set this up? (I could always hardcode these limitations, but there should be a better way) | ||
: And the main reason for this feature is the usage of clients over untrusted connections. Which is possible once you configured your client password via a trusted connection. | : And the main reason for this feature is the usage of clients over untrusted connections. Which is possible once you configured your client password via a trusted connection. | ||
:--[[User:Exp|Exp]] 06:58, 27 January 2006 (CET) | :--[[User:Exp|Exp]] 06:58, 27 January 2006 (CET) | ||
| Line 12: | Line 13: | ||
The encryption specified in the protocol is poorly defined. AES is just a cipher, not a protocol; there are critical details missing, like the type of chaining being done; if its being used in stream or block mode; how replay prevention and other Mallory attacks are to be prevented; etc. Consider using an existing, well-understood crypto protocol. TLS comes to mind. [[User:Derobert|Derobert]] 02:22, 28 January 2006 (CET) | The encryption specified in the protocol is poorly defined. AES is just a cipher, not a protocol; there are critical details missing, like the type of chaining being done; if its being used in stream or block mode; how replay prevention and other Mallory attacks are to be prevented; etc. Consider using an existing, well-understood crypto protocol. TLS comes to mind. [[User:Derobert|Derobert]] 02:22, 28 January 2006 (CET) | ||
:Technically the suggested (this page is not the actual specification, it's for proposals) encryption | :Technically the suggested (this page is not the actual specification, it's for proposals) encryption scheme is, in fact, perfectly well defined if you presume that messages can be padded beyond the end of the one line they are allowed to contain to a multiple of the block length (128 bits). However, it isn't very useful as a security measure because of the obvious vulnerability you point out: replay attacks. (This means that you can just parrot encrypted packets and they'll decrypt to the same plain text. So while you can't get the user's password, you can authenticate yourself as a user whose traffic you've monitored.) | ||
:...but in reality, there's no need for AniDB to be a secure application. Best to just forget about encryption altogether; it's far more trouble than it's worth in this case. | :...but in reality, there's no need for AniDB to be a secure application. Best to just forget about encryption altogether; it's far more trouble than it's worth in this case. | ||
:--[[User:Pelican|Pelican]] 20:45, 28 January 2006 (CET) | :--[[User:Pelican|Pelican]] 20:45, 28 January 2006 (CET) | ||
| Line 29: | Line 30: | ||
I'd like this command to cope with a couple of different encodings when passed a title, and be explicit over whether it finds only one result or does a best-match guess. --[[User:Rar|Rar]] 04:51, 30 Oct 2005 (CET) | I'd like this command to cope with a couple of different encodings when passed a title, and be explicit over whether it finds only one result or does a best-match guess. --[[User:Rar|Rar]] 04:51, 30 Oct 2005 (CET) | ||
: On second thought, is a wide search really wanted or is 'WHERE lower(name)=' good enough?. About encodings, do you care to elaborate? --[[User:Epoximator|Epoximator]] 18:24, 25 November 2005 (CET) | : On second thought, is a wide search really wanted or is 'WHERE lower(name)=' good enough?. About encodings, do you care to elaborate? --[[User:Epoximator|Epoximator]] 18:24, 25 November 2005 (CET) | ||
::Oh, specifically, I'd like anime lookups to be able to take sjis/utf8 rather than just html escaped ascii, as an option. While all real programming languages have trivial encoding switching: <code>string.decode('sjis').encode('ascii','xmlcharrefreplace')</code> some that might find a use for | ::Oh, specifically, I'd like anime lookups to be able to take sjis/utf8 rather than just html escaped ascii, as an option. While all real programming languages have trivial encoding switching: <code>string.decode('sjis').encode('ascii','xmlcharrefreplace')</code> some that might find a use for UDP access to AniDB (such as the dire mIRC scripting language), do not, so dealing with it server side would be nice. --[[User:Rar|Rar]] 01:28, 29 January 2006 (CET) | ||
This command should return all missing informations from ANIME, sush as companies, external links (ANN, ...), awards, ...--[[User:Darsh|Darsh]] 12:10, 19 April 2006 (CEST) | This command should return all missing informations from ANIME, sush as companies, external links (ANN, ...), awards, ...--[[User:Darsh|Darsh]] 12:10, 19 April 2006 (CEST) | ||
| Line 42: | Line 43: | ||
This could be included in the AUTH command or an environment command that includes options for encryption, encoding and compression. (In response to rar's request.) --[[User:Epoximator|Epoximator]] 11:48, 31 January 2006 (CET) | This could be included in the AUTH command or an environment command that includes options for encryption, encoding and compression. (In response to rar's request.) --[[User:Epoximator|Epoximator]] 11:48, 31 January 2006 (CET) | ||
: This should | : This should definitely become an additional, optional parameter of the AUTH command. There is really no reason why this should be an extra command. It just means two more UDP packets overhead on each client connection. --[[User:Exp|Exp]] 05:28, 8 February 2006 (CET) | ||
:: I think epoxi was more thinking of this command as setting a session state flag, like a parameter in AUTH would, rather than being sent prior to *every* command, which would of course be silly. I see no reason not to have both. --[[User:Rar|Rar]] 16:21, 10 February 2006 (CET) | :: I think epoxi was more thinking of this command as setting a session state flag, like a parameter in AUTH would, rather than being sent prior to *every* command, which would of course be silly. I see no reason not to have both. --[[User:Rar|Rar]] 16:21, 10 February 2006 (CET) | ||
| Line 55: | Line 56: | ||
breaking API for older clients. | breaking API for older clients. | ||
On updates, only the list of possible fields | On updates, only the list of possible fields | ||
need to be | need to be extended. -- --[[User:Dinoex|Dinoex]] | ||
: I think it's a good idea. Modified a bit. --[[User:Epoximator|Epoximator]] 13:38, 26 November 2005 (CET) | : I think it's a good idea. Modified a bit. --[[User:Epoximator|Epoximator]] 13:38, 26 November 2005 (CET) | ||
| Line 73: | Line 74: | ||
: done. --[[User:Epoximator|Epoximator]] | : done. --[[User:Epoximator|Epoximator]] | ||
=== MYLISTDEL: Delete file from | === MYLISTDEL: Delete file from MyList === | ||
Feature request: It'd would be neat if i could delete files from MYLIST using the file's hash and size like the MYLISTADD command. I'm writing a client that doesn't use lid or fid, only size and ed2k hash for all files. I could use the FILE function to obtain the fid, but that would be an unwanted extra step. | Feature request: It'd would be neat if i could delete files from MYLIST using the file's hash and size like the MYLISTADD command. I'm writing a client that doesn't use lid or fid, only size and ed2k hash for all files. I could use the FILE function to obtain the fid, but that would be an unwanted extra step. | ||
'''Command String:'''<br | '''Command String:'''<br> | ||
by size+ed2k hash: | by size+ed2k hash: | ||
* MYLISTDEL size={int4 size}&ed2k={str ed2khash} | * MYLISTDEL size={int4 size}&ed2k={str ed2khash} | ||
| Line 85: | Line 86: | ||
* 411 NO SUCH MYLIST ENTRY | * 411 NO SUCH MYLIST ENTRY | ||
--[[User:Antennen|Antennen]] 15:16, 9 August 2007 (UTC)<br | --[[User:Antennen|Antennen]] 15:16, 9 August 2007 (UTC)<br> | ||
: done a long time ago, just not documented.. --[[User:Epoximator|Epoximator]] 14:50, 25 December 2007 (CET) | : done a long time ago, just not documented... --[[User:Epoximator|Epoximator]] 14:50, 25 December 2007 (CET) | ||
=== NOTIFYGET: Get Notification/Message === | === NOTIFYGET: Get Notification/Message === | ||
Feature request: When you get the notification you only find the anime name and the anime id in it. It would be better if you can also get the file id with this notification, so you can find out which group has released the movie. It is a headache to find the groupname in the HTTP page, if you have in mind that when more than one group release a movie in one day and you have to find out which you | Feature request: When you get the notification you only find the anime name and the anime id in it. It would be better if you can also get the file id with this notification, so you can find out which group has released the movie. It is a headache to find the groupname in the HTTP page, if you have in mind that when more than one group release a movie in one day and you have to find out which you want to have... | ||
--[[User:raboni|raboni]] 17:13, 6 Sep 2006 (GMT+1)<br> | --[[User:raboni|raboni]] 17:13, 6 Sep 2006 (GMT+1)<br> | ||
: --edited by [[User:raboni|raboni]] 19:30, 7 Sep 2006 (GMT+1) | : --edited by [[User:raboni|raboni]] 19:30, 7 Sep 2006 (GMT+1) | ||