Inbox not syncing or logging of [#775]

Could it be that you are running an older nginx version with a known vulnerability? Unless Ubuntu has backported the fix to nginx/1.10.3 of course. Latest nginx is 1.13.9

I have left the webmail open since this afternoon and it is not syncing automatically with the latest new messages which I see on my phone and in Thunderbird. Clicking through different folders or on compose and going back doesn’t have an effect.

Is there an automatic log-off functionality after session has expired?
If yes, it is not working …
If no, might be a good thing to add from a security point of view.

Cookies say this at 26 Feb at 21:28 :
Cookie user_session : February 26, 2019, 3:08:15 PM GMT+1
Cookie mysessid : February 26, 2018, 5:51:12 PM GMT+1
Cookie webserver_cluster : February 26, 2019, 3:51:12 PM GMT+1

I think the expire time of cookie user_session should be checked. To leave that a year in the future for a secure webapp might be “a bit much”.

Apart from this, in my javascript console I see a few errors appearing like :

ERROR TypeError: e is undefined Stack trace: ix</t.prototype.fetchMessageJSON/<@ tf</n.prototype._next@ x</ tf</n.prototype._next@ x</ a@ Z</f</e.prototype.invokeTask@ onInvokeTask@ Z</f</e.prototype.invokeTask@ Z</u</r.prototype.runTask@ Z</h</t.invokeTask@ d@ v@ aot-rmm7-bundle-201802150957.js:1:27008 oe ae</t.prototype.handleError next Ge</n.prototype.subscribe/r< C</n.prototype.__tryOrUnsub C</ x</n.prototype._next x</ K</ Ge</n.prototype.emit onHandleError/< Z</f</e.prototype.invoke Z</u</ Xe</t.prototype.runOutsideAngular onHandleError Z</f</e.prototype.handleError Z</u</r.prototype.runTask Z</h</t.invokeTask d v

While typing this message, another error appears which has something like a 403 in it and says login. Maybe this has to do with auto log off? But why would it continue after this with going over part of my mail folders?

ERROR {…} _body: "<HTML>\n<HEAD>\n<TITLE>Runbox Login</TITLE>\n<STYLE type=\"text/css\">\n<!--\ntable.main { margin-top: 50px; width: 525px; border: 2px solid #155d96; background: #EEF2F7; padding: 0; text-align: center; }\ntable.main td.header { background: #155d96; text-align: right; vertical-align: bottom; }\ntd \t { font-size: 1.5 em; }\n.login { width: 300px; border: 1px solid #155d96; background-color: #fff; padding: 10px; }\nh4\t\t { margin: .5em 0; font-size: 1.2em; }\nul { display: block; width: auto; text-align: center; padding: 0; }\nli\t\t { padding: 2px 10px 0px; display: inline; }\ndiv.body,\ndiv.login-pageinfo { font-size: 1.2em; line-height: 1.5em; text-align: center }\ndiv.login-pageinfo p { font-size: 1em; line-height: 1.5em; text-align: center }\ndiv.msg\t\t { font-size: 1em; line-height: 1.5em; text-align: center }\nlabel\t\t { font-size: 1.2em; line-height: 1.5em; }\nbutton \t { 10px 0; font-size: 2em; line-height: 2em; }\nul.features\t …" headers: {…} _headers: Map { connection → […], "content-encoding" → […], "content-type" → […], … } _normalizedNames: Map { connection → "Connection", "content-encoding" → "Content-Encoding", "content-type" → "Content-Type", … } __proto__: Object { append: Xu</t.prototype.append(), delete: Xu</t.prototype.delete(), forEach: Xu</t.prototype.forEach(), … } ok: false status: 403 statusText: "Forbidden" type: 2 url: "" __proto__: Object { constructor: n(), toString: rc</n.prototype.toString() } aot-rmm7-bundle-201802150957.js:1:27008 us false aot-rmm7-bundle-201802150957.js:1:736498 folder:"Inbox" aot-rmm7-bundle-201802150957.js:1:737340 us false aot-rmm7-bundle-201802150957.js:1:736498 folder:"AbnAmro" aot-rmm7-bundle-201802150957.js:1:737340 us false aot-rmm7-bundle-201802150957.js:1:736498 folder:"Accountant" aot-rmm7-bundle-201802150957.js:1:737340 us false aot-rmm7-bundle-201802150957.js:1:736498 folder:"Amazon" aot-rmm7-bundle-201802150957.js:1:737340 us false aot-rmm7-bundle-201802150957.js:1:736498 folder:"Inbox" aot-rmm7-bundle-201802150957.js:1:737340 us false aot-rmm7-bundle-201802150957.js:1:736498 folder:"Inbox" aot-rmm7-bundle-201802150957.js:1:737340

If there is anything you want me to do or check please let me know. Can also do screen sharing if a developer wants to have a look.

Ubuntu handles security patching of nginx, also in this case.

The reason the app doesn’t log you out automatically is that it checks email automatically every 10 seconds. We may consider changing this behavior, but it is similar to an email client in this sense.

I’ll check with our developers regarding the error message you included.

  • Geir

Did you have Runbox 6 open in another browser window/tab? If so it may have logged you out due to inactivity, causing the errors you saw in Runbox 7.

  • Geir

Could be, have been comparing R7 with R6 and Thunderbird at the time. It has been a week ago since I posted this so can’t remember the exact order of what I did and if R6 was still open. But why would it matter? I can’t imagine that R6 logout would destroy session cookie’s of R7. And even if you think it is smart, to have different webapps use the same domain and same cookies, it still doesn’t work properly.

If a session cookie is invalid, R7 should show the login screen immediately. Even clicking on a different mail folder or menu item it didn’t do that. Anyway, if a computer is in sleeping mode it can’t synchronize and therefore should have a timeout of x minutes and show login screen after waking up again.

Or are you really implying that the cookie user_session (with an expiry date of a year in the future) is the one validating a session with R7 and causing it to be logged in all the time?
This, without warning the user that if he or she is using this account on a shared computer, another user would simply have to open the browser and doesn’t have to login?

Runbox 6 and Runbox 7 use the same domain name ( and authentication regime, and it’s the cookie mysessid that controls the timeout after 2 hours.

However, Runbox 7 will currently continue checking for new email as long as the user is logged in (similar to an email client), while Runbox 6 will not. Session timeout after 2 hours is really no ideal solution, and anything significantly shorter would be annoying to some users. However, we could probably implement a user preference for this parameter in Runbox 7.

In the meantime closing the browser will invalidate the cookie, as will logging out of Runbox. If you’re on a shared computer you should always log out of (or close) any applications you are using at the end of a session, delete any locally stored data, and properly log out of the operating system account as well.

  • Geir

Guess we have different opinions on the first to points. User preference is not working if they use it on different devices with different time-out requirements. Eg, private vs shared pc.

If session is invalid, you should be automatically redirected to the login page. Which was not happing or at least, I didn’t see the login page. See also the 403 error msg.

I am disappointed with your last comment, especially for a company that has as a prime slogan “Keep your email secure and private”. It is not about what a user should do, it is about what users actually do. Not every user is understanding or capable of understanding what is happening behind the scenes. Otherwise everyone would be running ideally there own mail server. As a web developer you have the responsibility to help the user staying save. And yes, that can come at a cost in terms of usability. But my guess is that people who sign up for Runbox, do that for a reason and will accept certain trade-offs. Especially if you explain the reasoning behind some choices. Just my 2cts.

Yes, we need to fix this. We had it in earlier, but it was removed as it did not work properly. We will add a redirect to login back in for those cases.


vanecke: If a user preference for session timeout is unsatisfactory then a 2-hour default timeout isn’t really satisfactory either. For some devices a 10 minute timeout would be suitable, for others a 2 hour timeout would be appropriate, and for many no timeout at all would be preferable. We haven’t decided anything yet, so your feedback is useful.

In the meantime we also see it as one of our primary missions to help educate users about security and privacy. Therefore we will continue informing users to increase their awareness about security aspects such as session hygiene.

The Runbox 6 related timeout issue resulting in the HTTP 403 error has been added to our todo list as issue #775.

  • Geir

To describe all the options in detail would take too much time. But here a few options :

Trusted device vs untrusted device :
First of all, use 2FA to know if a device is a trusted device. Could be as simple as email validation / warning like Facebook or Gmail does or make it fancy and give user the options like LastPass does. Could even be part of a premium package.
A simple solution could also be to provide a pincode after logging in. If you use eg a pincode of 6 numbers, randomly ask for the numbers of say 3 positions. Even if someone would be looking over your shoulder and has seen your username and password, he/she would only see the 3 numbers of the pin code but not all 6 and next time, the numbers of other positions are asked so they still won’t be able to login.

On logging in, ask for the wanted session time and keep track of this per trusted device. Still enable temporary override for the session. Advise to only in case a device is not used by others, set option “to keep logged in” and only expire after x days of inactivity. The need nowadays to have the browser open all the time to know if you have a new email is less there most people have smart phones and setup their account there as well. That is probably already helpful and reducing the need for the use case of a long session time to be alerted on new email.

Session time is technically the wrong thing to use there if app is checking every 10 minutes, app will never have expiring session time. Better to speak of “allowed time of inactivity before auto log off and redirecting to login page”.
So, implement mechanism to check last activity by user. If last activity moment if longer ago then the set “inactivity time”, invalidate/remove session cookie and redirect to login screen.

On enabling index, add warning that this should not be done on shared computers or at least not in Internet cafe’s. Depending on if local storage has been encrypted, index can be allowed on shared computer at home. Otherwise, no go.

Option to view all open and recent closed sessions with related allowed session times and option to kill sessions on another device. The perfect solution would be if you have an audit trail which shows exactly which email has been opened / sent / etc from which device at which date and time. Another idea for a premium package?

On closing tab, not only closing window, remove/invalidate session cookie. Could of course be an issue if you have multiple tabs open and use session cookies for different apps. The situation that you would have multiple tabs open with a webmail app is probably unlikely.

Unrelated to save sessions but safety in general another idea for a premium package. Block access to email account with geo-fencing. Only allow from within country or from trusted ip’s. Could be an option to start a safe and secure vpn-service as well :-).

Since the last update, the indexing feature has been working really well. First time since being on the beta that it just works.


vanecke: Thank you for the elaborate suggestions. We have recorded your comment in our issue tracker.

  • Geir

Glad to hear that!

  • Geir