Created attachment 257047 [details] [review]
proposed patch

it adds a new entry in the connection dialog.

while the UI team can think in a better way to handle that, I think it doesn't hurt if we provide that option so that more users (like me) can use polari in a daily basis and thus provide more feedback - and hopefully patches :)

Any reason to re-implement the accounts UI? Why not just use GOA's UI?

Any Updates on this? Do we want this or not? I think if we want more users to use this on daily basis, we should consider this bug.

Created attachment 313997 [details]
On-demand server authentification

(In reply to Kunaal Jain from comment #3)
> Do we want this or not?

Support servers that require authentification: yes
Add it as rarely needed option to the dialog: no

(Telling users to leave a field alone unless they are sure it's needed (as the Connection Settings in the Online Accounts panel does) is really a red flag that a better solution is needed IMHO)

This has actually come up a couple of days ago[0], and I think we have a workable idea - attached a screenshot of a local proof-of-concept patch.

[0] https://bugzilla.gnome.org/show_bug.cgi?id=756344#c9

'authentification' is not a word. 'authentication' is.

(In reply to Adam Williamson from comment #5)
> 'authentification' is not a word. 'authentication' is.

Fixed locally, thanks!

Created attachment 320297 [details] [review]
entryArea: Don't grab focus unconditionally when becoming sensitive

Our current idea for supporting server passwords is to allow users to
enter a password on authentication errors using the header popovers in
the room list. As this may happen while the active room is connecting,
we should make sure to not steal the focus while the user is typing
her password.

Created attachment 320298 [details] [review]
utils: Add keyring helper methods

We will soon start to support server passwords, which should be stored
in the user's keyring, so add appropriate helper methods.

Created attachment 320299 [details] [review]
chatroomManager: Handle authentication channels

Currently the only way to use servers that require a password with
polari is to set up the password elsewhere (Settings, Empathy, ...)
and rely on empathy's auth client to handle the actual authentication.
In order to support server passwords ourselves, we need to be able
to handle telepathy's password authentication mechanism before we offer
the user a way to specify the password.

Created attachment 320300 [details] [review]
roomList: Allow users to provide a server password

Now that we support password authentication, allow the user to enter the
server password in the header popover on authentication errors instead of
merely pointing out the error.

Attachment 320297 [details] pushed as 8eb6f94 - entryArea: Don't grab focus unconditionally when becoming sensitive
Attachment 320298 [details] pushed as b3d7f44 - utils: Add keyring helper methods
Attachment 320299 [details] pushed as a86f26f - chatroomManager: Handle authentication channels
Attachment 320300 [details] pushed as 17f4efa - roomList: Allow users to provide a server password

Hi Florian.

How's that supposed to work?

I have an IRC proxy (bip, which requires a password) + SSH port forwarding.

So, in the custom server dialog I put 'localhost:10000' (which is the port ssh is listening to).

It stays 'connecting' forever... should it popup for the password? How to debug it?