View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005543||Taler||bank (demonstrator)||public||2019-02-05 17:05||2019-12-20 19:12|
|Reporter||davidak||Assigned To||Marcello Stanisci|
|Target Version||0.6||Fixed in Version||0.6|
|Summary||0005543: redirect loop on https://bank.demo.taler.net/profile|
|Steps To Reproduce||1. open https://bank.demo.taler.net/profile|
|Additional Information||It doesn't matter if you have the browser extension installed or not.|
|Tags||No tags attached.|
Hi Davidak, and thanks for all your reports!
This time, however, I cannot reproduce this error; neither in Firefox nor in Chromium. Maybe Christian can try also?
Thanks for the feedback.
I can reproduce it on 2 computers in Chromium 71.0.3578.98.
Try with my account:
||Yep, with that account it works for me, too!|
Yes, also reproduced with Firefox (with your account).
Here's what (very presumably) happens.
After the first report from davidak (0005542), I have created a new Exception to be triggered when someone uses numbers "too big". Now, the 'davidak' account has *still* those very big numbers in its history, and after the login is done the logic would touch one of those at some point and raise the Exception.
The exception handler does capture the exception, and after having formatted a nice error message, it _redirects_ the faulty connection to the /profile page.
Then this latter step will trigger the same exception again, and there the loop begins!
So IMO, there is no fix to the code to be made, as such big numbers will never be contained in any future history, thanks to the "big number" exception blocking them in the first place (namely when a wire transfer is attempted.)
I will try to delete the guilty database row and see if the error disappears though.
||Maybe the redirection to the /profile page is still an issue? First, why don't we get to see the nice error message? At least we could use a timeout before the redirect to /profile so we can read the error message? Second, if /profile generated the error, redirecting to /profile makes no sense. So that's something else we could test for and then not redirect to avoid recursive redirects?|
You don't see the error message because it's supposed to appear in a fancy bar *in* the profile page (that we don't see because of the loop.)
Then I completely agree that we should never redirect to a page that can generate errors; so I propose that for this particular case we handle the exception where it happens (and not let it be handled by middleware - that is now causing the loop), and in general we should keep /profile exception-free.
To answer your question about putting a timeout: this is not doable because it's the whole /profile page itself that is not renderable (no matter how long we want to show it); as soon as we try to render it, we hit one of those very big numbers that would cause the exception.
||8ae219d (stable branch) fixes this. The too big number in this case was the 'balance' of davidak account; now it doesn't raise any exception but it's rendered as "INVALID AMOUNT, PLEASE REPORT".|
|2019-02-05 17:05||davidak||New Issue|
|2019-02-05 17:05||davidak||Status||new => assigned|
|2019-02-05 17:05||davidak||Assigned To||=> Marcello Stanisci|
|2019-02-05 17:52||Marcello Stanisci||Note Added: 0013606|
|2019-02-05 19:06||davidak||Note Added: 0013607|
|2019-02-05 19:15||Christian Grothoff||Note Added: 0013608|
|2019-02-05 19:43||Marcello Stanisci||Note Added: 0013609|
|2019-02-05 19:43||Marcello Stanisci||Note Edited: 0013609|
|2019-02-08 14:01||Marcello Stanisci||Note Added: 0013624|
|2019-02-08 14:08||Marcello Stanisci||Note Added: 0013625|
|2019-02-08 14:13||Christian Grothoff||Note Added: 0013626|
|2019-02-08 14:45||Marcello Stanisci||Note Added: 0013627|
|2019-02-08 17:41||Marcello Stanisci||Note Added: 0013628|
|2019-02-08 17:41||Marcello Stanisci||Status||assigned => resolved|
|2019-02-08 17:41||Marcello Stanisci||Resolution||open => fixed|
|2019-02-12 23:18||Christian Grothoff||Fixed in Version||=> 0.6|
|2019-02-12 23:18||Christian Grothoff||Target Version||=> 0.6|
|2019-12-20 19:12||Christian Grothoff||Status||resolved => closed|