Previously, our code produced a Go panic when attempting to index an
empty slice of bucket user agent entries. A length check has been
added to ensure that the slice is not accessed beyond its bounds.
Change-Id: I904ca275b934be1b05393a45d99ff415dcafc926
This change adds an endpoint that gets a user's settings. It will
create a new settings entry if no settings exists. There's also a new
endpoint to change a user's onboarding status.
Issue: https://github.com/storj/storj/issues/5661
Change-Id: I9941bb9d61994af46244003f3ef4fcfe7d36918e
This change updates the satellite frontend to retrieve its
configuration from the satellite.
References #5494
Change-Id: I1eb961f8a32f7d88173006117d41eddb57624692
This change adds onboarding_start, onboarding_end and onboarding_step
columns to the user_settings table. the first two are used to determine
if a user should go through onboarding, the last will be used to as the
step a user got to before exiting onboarding without finishing.
Issue: https://github.com/storj/storj/issues/5660
Change-Id: I8070c880d0d2fc22086f24087c962f57c695cc50
A Stripe backend implementation has been added that uses an exponential
backoff strategy to retry failed API calls. This behavior can be
configured in the satellite config.
References #5156
Change-Id: I16ff21a39775ea331c442457f976be0c95a7b695
We have a specific issue that a user uploaded a file to a bucket
geo-fenced to EU and one of the pieces appeared to be on a node in the
US. The country code of this node is set to SE (Sweden) in the satellite
DB. It turns out that some time ago MaxMind changed the country code of
this node's IP from Sweden to US, but this change hasn't been reflected
in the satellite's database.
So far the satellite updates the country code of a node only if its IP
changes. It was assumed that if the IP does not change, its country code
shouldn't change too. This turned to be a wrong assumption.
With this change, the satellite will look up the MaxMindDB on every
check-in to see if the country code of the node's IP has changed.
Change-Id: Icdf659b09be9fc6ad14601902032b35ba5ea78c4
if a drpc.ClosedError was returned, it would always take the
first (failure) branch, despite the second branch's existence.
Change-Id: Ife3b27869c4e9d37ca2914e2d1d1a2c60d326309
to support TCP_FAST_OPEN, we're considering just using
two TCP connections in parallel per request, one with
and one without. this allows us to safely fire both
concurrently without stressing out the node too much.
see https://review.dev.storj.io/c/storj/storj/+/9933
Change-Id: I9aa8a0252350db5ace04ee125bfe469203e980ec
There is a bug when switching passphrase outside object browser.
We don't generate edge credentials when switching passphrase so navigating to object browser shows old objects (for old passphrase).
By this fix we clear edge credentials every time user switches passphrase.
Change-Id: Ia09d559f90ae7f02ae5c778844beb7ec268356e7
Option added to `uplink access setup` and `uplink access create`
commands to disable object key encryption.
Related to https://github.com/storj/storj/issues/5678
Change-Id: I4789a94143742ff4b232fd60decc029ad2883c2a
License check is unlikely to fail, hence it's better to do it as part of
premerge rather than verify.
Also, fix indentation in Jenkinsfile.
Change-Id: Ifb37b92a88eb743a28847d84ed63c0e2e784dbe2
The account upgrade modal has been updated to display prices according
to the the user's price model. Previously, the modal displayed only the
default prices which were incorrect for users with price overrides.
Resolvesstorj/storj-private#187
Change-Id: I58206cc8ea7e7742a37f759a84dbb24ca40dd8eb
When a user logs in, we check if they have zero projects at the
dashboard. If so, the default project is created and they are sent to
the onboarding flow. However, this allows a user to skip onboarding if
they close out and log back in, since the dashboard is loaded first.
This change moves the default project creation to the beginning of the
overview step of onboarding to make sure any important preliminary
onboarding steps are not skippable.
Change-Id: I4fd1efc6ccd26b972fe57425efe268f8ba135c26
Add a combined index on normalized_email,status to improve performance of
common "get user" query used for the satellite UI.
Change-Id: I24a20d7826e0a68a68c2f95b5847eb819921e7c0
Using eventbus was a terrible approach because if session would expire in less than 3 mins then we would do an explicit API request to reset session for each upload progress ping.
With this change we simply check if there is at least one ongoing upload and refresh session with one single API request and we don't show inactivity modal.
This is a possible fix for this issue (at least I can't reproduce it):
https://github.com/storj/storj/issues/5618
How to test:
setup storj-up with InactivityTimerDuration config value set to 120 seconds.
go to object browser and start upload of some heavy file, for example 1GB.
check if inactivity timer would be shown in 2 mins, additionaly you may check DevTools network tab.
in my case upload is successfully done in about 3-4 mins without any problems.
Change-Id: I09142a7affac08db1d02992ca2d2f40c6267324f
Do not reset showing server side encryption banner for buckets page on relogin.
Issue:
https://github.com/storj/storj/issues/5555
Change-Id: I30d9d8e8370aa1fd1f60069720ecd07d8450c8ee
Upgraded chart.js dependency to V4.
Removed vue-chart and types/chart.js dependencies.
Refactored VChart component to rely only on chart.js dep without any additional wrappers.
Refactored VChart component to use SFC composition API.
Change-Id: Ic5e0131bff413f3205d4449db930644d113fe36d
This commit ensures that all invocations of Stripe library methods
include a context. This allows us to control the timeout and
cancellation of the underlying HTTP requests made by the Stripe
library.
References #5156
Change-Id: I8ddb317f3f2cbb06cfab869fbebdaf2ad78b7999
Metainfo needs to know rate and burst limit to be able to limit users
requests. We made cache for per project limiter but to make single
instance we need to know about limits. So far we were doing direct DB
call to get rate/burst limit for project but it's generating lots of
DB requests and can be easily cached as we even have project limit cache.
This change extends project limit cache with rate/burst limit and starts
using this change while creating project limiter instance for metainfo.
Because data size kept in project limit cache is quite small this change
also bumps a bit default capacity of the cache.
Fixes https://github.com/storj/storj/issues/5663
Change-Id: Icb42ec1632bfa0c9f74857b559083dcbd054d071
We just fixed case were project limit cache was not used properly. This
is test case to cover that fix.
Change-Id: Iee467f0a46836860a14ab6238a9842ffbf54ed4c
We have lots of direct DB requests to get API keys. It should be handled
by cache but default value is very low at the moment.
Fixes https://github.com/storj/storj/issues/5665
Change-Id: I214ebebd6e397cacff80b2f36dc4a2eea388f93d
This might be pretty awful, but at least it is a complete and non-flaky
solution.
**Only when using the rollingupgrade test** (which implies a throwaway
satellite and also a PostgreSQL backend), create a trigger on the nodes
table which forces last_net to be equal to last_ip_port always.
Change-Id: I8448cf131e46576d96a414d06780270c7b2b1892
Currently, to get number of entries in segments table we are doing
heavy SELECT count(*) operation. For biggest satellite it's taking
25min now. We are using this method to get stat before and after
segments loop so it adds almost 1h to overall loop time.
With current version of crdb we are using this additional code won't be
used because global configuration for stats refresh rate is inaccurate
for such large table like `segments`. Soon we should be able to upgrade
crdb and be able to adjust refresh rate per table and configure it to
satisfy defined threshold.
https://github.com/storj/storj/issues/5544
Change-Id: I05cfd9154f08894d2bc56bf716b436d1b03b87f1
We do regular testing with executing uplink. But sometimes the recorded execution time showed spikes.
Would be nice to know the reason of the spikes (just internet blip, or something what we should be worried about).
We can collect distributed traces, but it's not easy to find the right trace in Jaeger.
* We can provide a random trace-id, but it should be persisted / processed
* We can also save standard output and use `--trace-verbose` which prints out the used trace id, but it's also complicated to collect all of them in a DB
Would be nice to attach additional metadata to traces to make sure that we can filter all traces of one specific kind of test.
This patch provides this feature:
* It always adds hostname to the trace (if you opt-in to distributed tracing, which is turned off by default)
* Additional tags can be defined with CLI flag
Tags can be used to find the right trace in Jaeger (or in Elastic search backend of Jaeger).
Change-Id: I08f10023bbebd783f812cfca95ac6237360ac2b0
The Coupons area of the Billing page has been updated to match our
designs.
Resolvesstorj/storj-private#172
Change-Id: I0f3d7f3818f47a1bbc6a2dba930ab429f83f92c2
A field has been added to the coupon struct indicating whether it is
associated with a partner's pricing package. This is required to
alter the appearance of partner coupons in the satellite frontend.
References storj/storj-private#172
Change-Id: Ie48ae3902aaa108abf9a399242a0cd98cb53d1c3
This change sends an event to segment for when a user is unfrozen.
It also moves freeze and warning event triggers from the autofreeze
chore to the account freeze service.
Change-Id: I5c0522b921b7baf52d6db5eb7ef841c08644a461
A package has been written to generate a TypeScript file containing
classes corresponding to the frontend config. These classes will be
used across the frontend once we no longer reference meta tag values
for configuration.
References #5494
Change-Id: If425035892773167ac6d9fbfae8140cab79fbb70
The code responsible for generating TypeScript classes has been
separated from the rest of the TypeScript generation code so that other
packages may take advantage of this functionality.
References #5494
Change-Id: I97eabd430bd6a5f748eafaf8b1d783977e75e660
This change reworks the allowedAuthorization function to check what
groups the user is a part of to determine if authorization should be
granted. By wrapping each handler with withAuth, we can specify the
allowed groups for each api method individually.
github issue: https://github.com/storj/storj/issues/5565
Change-Id: I1804dda04d5b16d19e93bd7199fb3fc89fca1294
