Talk:UDP API DEV

Encryption

"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. --Suppy 06:41, 27 January 2006 (CET)

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.

--Exp 06:58, 27 January 2006 (CET)

Crypto Protocol

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. Derobert 02:22, 28 January 2006 (CET)

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.

--Pelican 20:45, 28 January 2006 (CET)

Well, the actual implementation by epoximator will define the exact encryption type and the API documentation will be updated to reflect this. I agree with pelican to a certain extend. The security needs of AniDB can be viewed as being rather limited. As such TLS seems like an overkill (especially since it brings quite some additional performance and bandwidth overhead). And even the very basic AES encryption will be disabled by default. And yes, replay attacks will be possible, but the damage an attacker can do with those should be limited. I'll add a small change to the protocol which will make replay attacks slightly more complicated, but still not impossible. The encryption should be kept as simple as possible in order to minimize the additional overhead.

And even a very basic AES encryption will be enough to prevent the password from being snooped while it is transmitted. I.e. in unsecured wireless network environments.

--Exp 04:55, 30 January 2006 (CET)

If TLS really is too much overhead, I'd suggest using ESP (from IPSec) with static keying (so you don't need the additional complexity of IKE). You can encapsulate that in a UDP packet, instead of IP proto 50.

I think, if you're going to give users a "secure" checkbox, it really ought to be secure. The best way to accomplish that is to use a well-understood, well-studied security protocol instead of inventing yet another. The "invent yet another" security protocols all too often turn out to be completely insecure.

BTW: If you're just trying to prevent password sniffing, there are already several well-studied HMAC-based protocols which do that, and do it with minimal overhead. Low enough that you could probably just use it by default.

—Derobert 14:56, 30 January 2006 (CET)

Done

ANIME

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. --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? --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: string.decode('sjis').encode('ascii','xmlcharrefreplace') 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. --Rar 01:28, 29 January 2006 (CET)

This command should return all missing informations from ANIME, sush as companies, external links (ANN, ...), awards, ...--Darsh 12:10, 19 April 2006 (CEST)

OK. But included in ANIME with an argument, like acode.--Epoximator 00:18, 21 April 2006 (CEST)

Thanks, but what about awards? Moreover I'm not sure that having few commands that returns a lot of data is the best solution. --Darsh 22:50, 01 May 2006 (CEST)

Added awards. Not sure what you mean... You only request what you need by setting the corresponding bits in acode. --Epoximator 11:02, 2 May 2006 (CEST)

I'm not sure of this, since I don't know how the server is implemented and how the database schema is, but doing so require a lot of work by the server. Moreover the available bits are only 32... --Darsh 19:07, 01 May 2006 (CEST)

ENCODING

Protocol 2 says that the current character encoding is “unknown.” Shouldn't this be defined, preferably to some Unicode, like UTF-8? Considering AniDB maintains data in several languages, isn't having an agreed-upon encoding important? Derobert 01:35, 14 November 2005 (CET)

I guess it's ok to set this to ASCII now. All non ASCII chars should be html escaped. --Epoximator 11:40, 27 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.) --Epoximator 11:48, 31 January 2006 (CET)

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. --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. --Rar 16:21, 10 February 2006 (CET)

GROUP

I obtain: '41|851|665|109|1004|Zhentarim DivX|zx|#zhentarim|irc.chatsociety.net|http://www.zhentarim.net/' The irc channel and irc server are on two fields, and this is not documented. --Darsh 12:14, 28 April 2006 (CEST)

Updated doc --Epoximator 20:52, 28 April 2006 (CEST)

FILE

Pass a list of fields (limit e.g. 10 entries) and return content. This makes it possible to request new fields in the database without breaking API for older clients. On updates, only the list of possible fields need to be extended. -- --Dinoex

I think it's a good idea. Modified a bit. --Epoximator 13:38, 26 November 2005 (CET)

Selection by anime, group and episode number is not unique. As an example: FILE aid=22&gid=41&tag=tag0002&epno=1
This commands always return only the first match. --Darsh 12:10, 19 April 2006 (CEST)

Can be fixed with MULTIPLE FILES FOUND, or just return the latest version. Maybe selectable with an argument.--Epoximator 00:18, 21 April 2006 (CEST)

Add {str anidbfilename} to fcode? --Darsh 10:56, 25 April 2006 (CEST)

ok. bit 30 @ fcode --Epoximator 21:34, 28 April 2006 (CEST)

EP

Also return airdate --Tesiph 11:27, 17 December 2007 (CET)

done. --Epoximator 14:50, 25 December 2007 (CET)

MYLIST

Add support for the 'type' field (original/corrupt/self edited/other) --Tesiph 11:33, 17 December 2007 (CET)

done. --Epoximator

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.

Command String:
by size+ed2k hash:

• MYLISTDEL size={int4 size}&ed2k={str ed2khash}

Possible Replies:

• 211 MYLIST ENTRY DELETED

{int4 number of entries}

• 411 NO SUCH MYLIST ENTRY

--Antennen 15:16, 9 August 2007 (UTC)

done a long time ago, just not documented... --Epoximator 14:50, 25 December 2007 (CET)

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 want to have... --raboni 17:13, 6 Sep 2006 (GMT+1)

--edited by raboni 19:30, 7 Sep 2006 (GMT+1)

The current system doesn't store fids, only count, when i think about it. This has to be approved by exp himself.--Epoximator 10:33, 24 September 2006 (UTC)

Err.. it does actually. still one bit missing, though --Epoximator 14:41, 2 January 2008 (CET)

Done --Epoximator 19:05, 11 March 2008 (CET)