[tor-bugs] #6708 [Onionoo]: Pyonionoo returns code 500 for a few parameters
Tor Bug Tracker & Wiki
torproject-admin at torproject.org
Sun Sep 23 15:38:50 UTC 2012
#6708: Pyonionoo returns code 500 for a few parameters
---------------------+------------------------------------------------------
Reporter: karsten | Owner: gsathya
Type: defect | Status: needs_review
Priority: normal | Milestone:
Component: Onionoo | Version:
Keywords: | Parent:
Points: | Actualpoints:
---------------------+------------------------------------------------------
Comment(by karsten):
Replying to [comment:4 gsathya]:
> Replying to [comment:3 karsten]:
>> - Searching by fingerprint or nickname works for partial search terms,
but searching for partial IP addresses does not work.
> There's no need to validate the IP address then('1' could be a partial
IP). Will fix
Yup. Note that '1' could also be a partial fingerprint or (partial)
nickname.
>> - Some specific search terms can be fingerprint parts or nickname
(parts), e.g., `"cafe"`, but 92dac32 would in that case only search by
fingerprint.
> This kind of sounds broken. I don't really see a use case where anyone
would want to search for parts of a fingerprint and nickname.
It's a question of usability. The user may know that she's searching for
a fingerprint or a nickname starting with "cafe", but if there's only a
single search field, she cannot specify that easily. Sure, we could
require fingerprints to start with "$", but that would confuse lots of
users searching for an existing fingerprint without leading "$" and
receiving zero results. If we return all relays which have their
fingerprint and/or nickname start with "cafe", the user can select the one
she wanted to search for.
Similarly, if we allow searches for the first octet of an IPv4 address,
that search could also return relays with that number as their partial
fingerprint or (partial) nickname. (See the '1' case above.)
>> Anyway, I wonder if there's an easier way to implement searching in
Pyonionoo: [...]
> Sounds like a fine idea to me and we can get rid of the addresses and
flags table. I prefer a single table approach.
Using a single-table approach for summary data sounds good to me. I'm not
even sure what we'd do with a flags table. We could easily add a single
boolean column for each flag.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6708#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list