| Commit message (Collapse) | Author | Age |
| ... | |
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fixes #6309, found by lunar.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Onionoo's protocol specification says "Omitted if the relay does not
accept directory connections." Let's do what the spec says.
|
| |
|
|
| |
Implements #5247.
|
| |
|
|
|
|
| |
Works only for search=... parameter, not for search/... URLs.
Implements #5248.
|
| |
|
|
| |
Implements #5245.
|
| | |
|
| |
|
|
| |
Implements #5251.
|
| |
|
|
| |
Implements #5960.
|
| | |
|
| |
|
|
|
|
|
| |
We used a JSON-formatted summary document and a .csv file to decide which
relays and bridges to return in the servlet. This is overly complex and
unnecessary. We have a fine summary file that contains all information we
need and that can be easily extended.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Bridges got the running bit if they were contained in the last known
status, regardless of a possibly missing Running flag. This doesn't
matter for relays, because all relays in the consensus have the Running
flag. That's not true for bridges.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Parameters are more flexible than our current URLs. Current functionality
can be implemented with the type, running, search, and lookup parameters.
The order and limit parameters can be used, e.g., for top-10 lists of
relays by bandwidth. The offset parameter might be useful for paged
results.
This is a major API change, so we're leaving the deprecated methods in for
two months instead of one.
|
| | |
|
| | |
|
| |
|
|
| |
This .jar is now required by metrics-lib.
|
| | |
|
| |
|
|
|
|
| |
All details files with descriptor details now contain a last_restarted
field, and if they don't contain descriptor details we won't be able to
write a last_restarted line anyway.
|
| | |
|
| |
|
|
|
|
|
|
| |
If we parse a relay or bridge server descriptor that we never saw before
and learn about the relay or bridge in a later consensus or status, we'll
never write the descriptor content anywhere. The result would be details
files containing no descriptor parts until the relay or bridge publishes
the next descriptor. Yes, this took a long time to track down.
|
| | |
|
| |
|
|
|
|
|
| |
So far, we assumed that the webapp is deployed as ROOT.war which means
URLs are, e.g., /summary/all. Now we allow the webapp to be deployed as
onionoo.war which leads to URLs like /onionoo/summary/all. Handle both
variants.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
More precisely, accept hashed relay fingerprints and hashed hashed bridge
fingerprints.
The problem addressed here is that both */lookup/ and */search/ URLs
require a non-hashed fingerprint to look up a relay and a hashed
fingerprint to look up a bridge. This works fine if a) users know how to
hash fingerprints and b) the client knows whether the user provided a
hashed or non-hashed fingerprint. But what if either a) or b) is not the
case? If the client sees a 40-character fingerprint it shouldn't simply
submit it to the server. It might be a non-hashed bridge fingerprint.
The change made here is to make */lookup/ and */search/ URLs accept hashed
relay fingerprints and hashed hashed bridge fingerprints. Clients can now
be advised to always hash any 40-character hex input they receive from
users and include that in their request to the server. If the user
provides a non-hashed fingerprint of a bridge the client won't reveal the
non-hashed fingerprint in the URL. If the user provides a hashed
fingerprint, looking up the hash of the hash still works and returns the
bridge the user was looking for.
Implements #5368.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
From GitHub issue #2: "We include bandwidth data for all time periods as
soon as we have at least two data points. But sometimes a time period is
completely contained in another, shorter time period, where graphs have a
higher resolution. For example, if a relay is only running for a few
months, we don't need to include bandwidth data for the 5-years graph, but
only for the 1-year graph. In general, we only need to include bandwidth
data up to the point where the start of a time period precedes the first
bandwidth data point. No need to include larger time periods."
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|