| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
If we get any problem with the upload of the user's public key,
we are deleting the key pair from the local database and denying
login. That way, a new login will have a chance to regenerate the
key and upload it properly.
|
|
We covered a lot of missing cases on the keymanager tests. We also
isolated these tests, that caused some other tests to break, so we
fixed them.
|
|
|
|
The functional tests depend on a pre-existing default user. As it uses
the integration test client, we added this default user to the client
setup.
|
|
The login resource was being totally mocked out of the integration
tests, I adapted the test client to touch the actual login code
and fixed the multi_user_client to use the same checker the single
user one was using. With that change we now have tests that cover
the change of authenticating with bonafide
|
|
To ensure we don't overload the server with requests, we'll
sleep a little bit before each request to check if the inbox
is already loaded
|
|
It now requests using the same session that it logs in until the user
arrives at the inbox (denoted by the compose-trigger showing up on the
html in this case)
|
|
|
|
|
|
I added a new test to check that an existing public key is not being
sent to leap on every login
|
|
|
|
|
|
|
|
Since we are creating the combined certificates at the beginning
of the UA and using it for multiple users, it makes more sense to
create it in the leap folder instead of on a temporary file
This bundle will be updated on every UA start
|
|
|
|
|
|
|
|
With this change we don't have to create the combined_ca_bundle
for every user at every login.
To support this change, we started migrating away from the
LeapCertificate class that was making the LeapProvider setup
more brittle
|
|
|
|
We had different outputs for inlineCallbacks
and traditional callbacks and the output was
kinda confusing. We normalized the output to
<time> <type>: function <name> (<file>:<line>) in thread <thread_id>
We also changed the earlier type from deferred
to callback (because that is what's being measured)
so now we have two possible types: callback and
inlineCallbacks
|
|
The inlineCallback returnValue has a different logic using
exceptions, the way we measured before, we were getting the
time of the whole deferred chain (including all the callbacks)
instead of exclusively the timing of the last yield up to the
returnValue call.
|
|
This reverts commit 480e7d3bd48f2a7c23a76843750daaa03f2b12b3.
|
|
This reverts commit 8ef8acf8e853fe097c379eed4d65e67f409531d1.
|
|
|
|
|
|
We did two changes to the twisted patch to be able to
measure the inlineCallbacks correctly:
- Filtered the traditional callbacks timing so that it
doesn't print inlineCallback timings
- Added a measurement for the g.send() method inside
the inlineCallback, to measure the actual execution
time of the call on the main thread, between the
inlineCallback yields
|
|
|
|
|
|
See #761
|
|
|
|
|
|
See: #761
|
|
|
|
|
|
|
|
|
|
The README explains how to apply the patch so you
can get information about long running methods (longer
than 100ms) on the main thread
|
|
Started adapting get_leap_session to deferreds
Soledad and keymanager setup calls will now
happen in deferreds and leap session creation
itself is a deferred with callbacks
This is a start in breaking the big blocking
calls we were doing on the main thread, this
was done without changing code inside the
leap libraries yet so things can be further
optimized
This breaks the ~4 seconds get_leap_session
piece into smaller 1 seconds one, that can be
further optimized and deferred to even smaller
calls
There are requests calls happening on the main
thread that should get this number even further
down
Also moved some pieces from bitmask libraries
to our bootstrap, because they are not bitmask
libraries anymore and that was causing confusion
|
|
Consolidated authentication to always be
done is a defer to thread and changed the
authenticate_user method name to conform
with what it actually does
|
|
|
|
|
|
fixing build -- Issue #694
|
|
|
|
services sessions
|
|
|
|
|
