Eberhard/all, Thanks, we'll probably discuss this tomorrow with those who come to Zurich and interested other JCP Members.
Werner On Mon, May 13, 2013 at 8:40 AM, eberhard speer jr. <[email protected]>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Like Werner, I have played around with the Java webservice and like > Werner, I say : great stuff. > > Seeing as I run a very similar service (see below) which currently > gets anywhere between 5k to 10k hits per day, I like to share some of > the issues I ran into and some points for discussion. > > 1) user-agent in URL query-string > Some servers, in my opinion quite rightly, are configured to refuse > requests with 'dodgy' character sequences in their query string (like > complete URLs with their own query string), such as may occur in some > of the more exotic user-agent strings. > Security considerations may also, again quite rightly, be invoked to > limit the length of URL and/or query string of a request. > > In short, including the user-agent string in the query string can > justifiably be said to open a potential attack vector on a host. > > When running tests on the initial version of the web-service, with ua > in URL and after relaxing the host's security settings with regard to > acceptable requests, every 'script-kid' and his dog tried and kept > trying to find a way to break things. > > The solution I chose and propose : including the ua to be resolved in > a custom HTTP header (Ddr-User-Agent), while forcing the requestor to > employ a bit more code, has, I think the following advantages : > > - - forcing the requestor to employ a bit more code -- the > template/boilerplate can be made available for various > stacks/languages as part of DeviceMap -- adds a bit of 'security thru > obscurity' and deprives 'script-kiddies' etc from their 'fun', saving > resources (bandwidth and time) as well as avoiding possible security > headaches > - - the security issues mentioned above are no longer an issue for the host > - - the service can differentiate between the ua (and optionally IP) of > the requestor and the ua (and optionally original source IP) being > presented for resolution (the service would 'read' x-forwarded-for as > the IP belonging to the ua in the Ddr-user-agent header, while all > other HTTP headers retain their function/meaning) > > 2) response > Judging from the feedback I got, 'clients' prefer to get only those > key-value pairs for which a 'real', i.e. non-empty, non-default, value > exists. > If a key is not present in a response, the client is *knows* it's > value and depending on their requirements can then implement their own > suitable defaults. > > This appears to be a significant issue. Others who provide similar web > services appear very 'complete' and up-to-date in that they return a > value for practically every known property for just about any ua. > However, this is regarded as 'cheating' since the 'client' spends time > processing responses and basing routing and content/formatting > decisions on values of which the value (pun intended) is unknown. > > Some keys however are expected in *every* response, such as, for > example : IsDestop, IsMobile, IsBot,... a time stamp and version info > of the data set. > > 3) 'esthetics' > "Les gouts et les couleurs...", I know, but to me an ua in an URL just > looks...off. "It's just not cricket" ;-) > > > Finally : the below of (see below) : > I have described the service here earlier. It basically uses the > DeviceMap, ex-OpenDDR, resolver code and the current DeviceMap data, > and it's responses are -- as far as I can tell now -- identical (same > device id). > I will make the UA's 'harvested' from the web service I mentioned > available as soon as possible and with regular updates. > I think that to this end we may want to revisit the points raised on > the whats and the hows involved. (log date, ua, IP, country,...) > > What do you think ? > > esjr > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRkIr1AAoJEOxywXcFLKYcUm0H+gP6oYN/dZZU5JNXouRd/40u > E7m+CBnWhvBMNacHY+KbojycUmr+GkjbXIdD5IUMoQqfI7Z3wtR62Y0QI3JM+X05 > vIP7HGdspe5BpfvQfeuMdu3epbObEP/7ovlfaqg1k3tcX58z3oJBXRH2EYCHtHhz > aP9PYMddolyaNlVKvd8vcpovp/HI1wuBqXaPiVcHsuCGqUN2tk5rNhCLaWJNTKJl > K1OVeG08UAkQ2b4VFNC2PGOuEmcSA7DMaiISGYVkQHi/0LdHfqYX5bzc1IXrK0qK > iRaXA9UgrK9OZ5miztnjbUyIcf5Q+qj5Za42ID0f5YYWoPivcRZW9tgaHB6OFUQ= > =0vdz > -----END PGP SIGNATURE----- >
