vanstyn / RapidApp / 734
51%

DEFAULT BRANCH: master
Ran
Jobs 6
Files 94
Run time 28min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
734

push

travis-ci

vanstyn 
ReAuthPrompt correctly handles simultaneous requests

In apps which have auth enabled, Ajax requests which happen after the
user's session is no longer valid (i.e. do to timeout or otherwise
becoming logged out for whatever reason) the back-end will trigger a
"reauth" which will present a window to allow the user to log back in
and then upon success, the original request will be re-tried...

This works fine in most cases, however, if something generates
multiple requests at the same time, multiple reauth dialogs could be
shown at the same time.

This has been fixed in this commit, which establishes a "queue" to
hold reauth callbacks, and checks to see if a reauth dialog is already
shown, and simply adds the callback to the existing queue instead of
showing another window. Meanwhile, upon successful reauth, the
original reauth dialoag calls all the callbacks in the queue, even
if they have been added later. The benefit of this design is that
multiple windows are avoided AND callbacks aren't lost for the
subsequent requests.

NOTE: for safety, for now, the queue is limited to 5 callbacks, to
avoid a situation where a massive number of queued requests could
happen all at once (for instance if there is a situation where
an automated request is happening on a timer and the user leaves
their screen up all night). The 6th and later callback currently
are just dropped. This could lead to interface inconsistency, but
it is the safest thing to do for now.

TODO:

Later on, we should investigate a more proper solution, such as
1. prevent new requests from happening when a reauth is happening
(if that is even possible, which it can't be in all cases) or
2. have some cut off that if there are too many queued callbacks
or if it has been sitting for two log, it just loggs the user out
or otherwise locks the interface. But, for now, the new behaviour
is at least a lot better than how it was

3187 of 6250 relevant lines covered (50.99%)

1382.97 hits per line

Jobs
ID Job ID Ran Files Coverage
1 734.1 94
51.07
 Travis Job 734.1
2 734.2 94
51.07
 Travis Job 734.2
3 734.3 94
51.07
 Travis Job 734.3
4 734.4 94
51.07
 Travis Job 734.4
5 734.5 94
51.05
 Travis Job 734.5
6 734.6 94
51.05
 Travis Job 734.6
Source Files on build 734
Coverage ∆ File Lines Relevant Covered Missed Hits/Line