searching atlas for email addresses fails

[cypherpunks]

I'd like to be able to search atlas by email address. Currently, queries with an "@" in them results in

Backend error!

The backend server replied with an error to your query. This probably means that you did not properly format your query. If your query was properly formatted it may mean that there is an issue with your browser/add-ons. Please report which browser/addons/etc. you're using to the bug tracker.

I'm using TBB 3.5.2 with its default set of extensions.

[phw]

Right now, Atlas can't do that but the backend (onionoo) supports it. As a result, you can search for contact information manually by opening:
https://onionoo.torproject.org/summary?contact=user@domain.com. Instead of summary, you can also use details, bandwidth, or weights. More information about the backend is available here: ​https://onionoo.torproject.org/

Unfortunately, Atlas does not have a maintainer who's fluent in JavaScript, so I can't promise that this will be fixed anytime soon. Patches are always welcome, though.

[karsten]

This issue is unrelated to Atlas and is in fact an Onionoo issue. The query that phw mentions, https://onionoo.torproject.org/summary?contact=user@domain.com works just fine, but Atlas does not (and should not) pass its search string to Onionoo via the contact parameter. Atlas should instead pass everything it gets from the user to the search parameter.

Here's how this is supposed to work as of Onionoo protocol version 1.2, which was published in October 2014, half a year after this ticket was opened: Atlas users would use a qualified search term like contact:user@domain.com to search by contact.

However, and here's the bug, Onionoo's search parameter check is more restrictive than its search parameter. For example, the contact parameter accepts the @ character as input just fine, but the search parameter responds with 400 Bad Request. We should fix this, and then Atlas users can search by contact email address.

Please review ​my Onionoo branch task-10972.

[iwakeh]

All fine. Ready for merge.
Should we have a 3.1-1.0.1 release?
Or, add this to 3.2-1.1.0, which is also on the way?

[karsten]

Oh, that was quick. Thanks for reviewing! Merged!

Regarding the release, I'd say 3.2-1.1.0, unless that gets delayed a lot. But this bug was around for years, so what's another week or two.

[iwakeh]

Fine, setting it to next release milestone. (Assuming with high probability there won't be an earlier release.)

[iwakeh]

Closing.

Thanks.

[iwakeh]

There won't be 3.1-1.1.0.