Revisions and Commits
| Unknown Object (Diffusion Commit) |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • chasemp | T1047 Phabricator lacks a "notification" feed similar other project management software: Enable "Flame" | |||
| Resolved | • mmodell | T75791 Following Notification from "bell" menu does not clear notification | |||
| Resolved | • mmodell | T103444 Desktop notifications | |||
| Resolved | • mmodell | T97650 Conpherence wont refresh chat messages automatically, needs manual reload | |||
| Resolved | • mmodell | T765 Enable notification server (real-time pop-up notifications) in Phabricator | |||
| Resolved | BBlack | T112765 Phabricator needs to expose notification daemon (websocket) | |||
| Resolved | • csteipp | T1286 Aphlict security review |
Event Timeline
There is ongoing work to get rid of Flash and use WebSockets. Should we resolve this task as Stalled in the meantime?
https://secure.phabricator.com/T6559 has been resolved as Fixed. In principle, Aphlict has no dependency on Flash anymore.
Being Aphlict and dependencies fully open source now, does it still require a security review?
Sorry, that was ContentTranslation, which is done. I'm working on a couple things, should get back to this next week.
@csteipp: the only challenge with the new incarnation of notifications, is that we need to proxy the websocket connection through our varnish and nginx reverse proxies (phab has two layers of proxies in front of it for horribly bad reasons I don't wanna talk about)
but the aplict server it's self is a fairly straightforward nodejs-based websocket thing.
https://secure.phabricator.com/book/phabricator/article/notifications/
Upsteam did a nice refactor of everything, so no longer blocked on their use of flash. I found one potentially blocking bug in the new service, I need to get that verified and reported to them, then we should be ok to deploy. Sorry for the delay.
@Negative24: besides security review this is also blocked by ops: need to tunnel the websocket through two layers of reverse-proxy servers.
As I said on email, it was scheduled for last week, then stuff happened.
Should be next week.
Ok, things look mostly ok as long as we take a couple of precautions running this in production:
- Don't configure a logging file-- too much opportunity for DoS (arbitrary length messages from users are written into the log), and there might be some privacy impact since it logs remote ip + user ids.
- Make sure the admin host remains 127.0.0.1 (default setting). Anyone with access to that port can be a very painful nuisance to other users.
@csteipp: I know you have your own workflow on some things, so should I not close this task as resolved and let you do it? :)