Project

General

Profile

Actions

Feature #4627

closed

Add a separate Ident field in the serverlist

Added by Robby K almost 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Interface
Target version:
Start date:
06/22/2019
Due date:
% Done:

0%

Estimated time:
Operative System:
All

Description

Add a separate Ident field in the serverlist.

Currently the value of the "Username" field is used for both SASL authentication and as the ident sent in the USER command when logging into IRC. This forces the ident of the user to be their SASL username which is a problem if the ident needs to be different from the SASL username.

It would be great if there was a new separate "Ident" field for the ident, so that the "Username" field is only used for SASL.

Ideally, the current "Username" field should be changed to become the "Ident" field so that it can stay in the same place in the interface, and a new "Username" field added below the login method drop down menu, because currently the SASL username and SASL password fields are separated from each other which is a bit weird with regards to interface layout.


Files

Ident field-2-edited-annotations.png (55 KB) Ident field-2-edited-annotations.png Revised General tab in the Serverlist Robby K, 06/22/2019 07:48 PM
serverlist.png (30.5 KB) serverlist.png Per Amundsen, 08/15/2019 01:14 PM
Actions #1

Updated by Per Amundsen almost 5 years ago

What is the use-case where you need separate username and ident? Most clients seem to do things this way.

I also feel like the Serverlist is already confusing&/crowded, but it could be added to the Misc tab, where any non empty value would just override the Username.

Actions #2

Updated by Robby K almost 5 years ago

The use-case here is to not be required to adjust different things like access lists from bots which recognize you based on your nick!ident@host mask when using AdiIRC while having a different SASL username/account. Also, people might simply like to use an ident which is different from their SASL username.

mIRC for example does not have this issue, there it is done like this: whatever value you put in as the ident in the Identd settings is used as the ident in the USER command during login into IRC, even if Identd server is enabled or not, no matter if you use SASL authentication or not. The password field for SASL in mIRC takes the syntax "username:password", which effectively makes it so its only used for SASL.

On Android, the Revolution IRC client also has separate fields for this and so is not an issue there either.

About Serverlist being crowded, how about having a separate SASL tab instead? This would create space in the General tab and then Ident could be added to the General tab after all, as I feel like that is where it belongs. I also feel like a non empty-value should override the Identd's value instead of the Username value.

Using my MS Paint skills I have made some changes to a screenshot, of what a slightly revised General tab could look like and have attached it.


Side-note: While editing this screenshot I have also realized now that it is not possible to set different server passwords (/PASS) for each individual server in a network, but only one global server password in the General tab for all servers in the network in the Servers tab. But that is another issue/feature request.

Actions #3

Updated by Robby K almost 5 years ago

Also, in hindsight, the "SASL Username" and "SASL Password" in the screenshot are somewhat wrong names because of the other non-SASL login methods. Maybe a separate SASL tab (or even better, Authentication tab?) is better, with just the login method drop down menu and the "Username" and "Password" fields.

Actions #4

Updated by Per Amundsen almost 5 years ago

I don't think 99% of users knows what a "ident" is, adding it as a major field would just cause more confusion, if I am adding it, it's gonna go to the Misc tab.

mIRC for example does not have this issue, there it is done like this: whatever value you put in as the ident in the Identd settings is used as the ident in the USER command during login into IRC, even if Identd server is enabled or not, no matter if you use SASL authentication or not.

I think this is the right solution, an option to use the User id from Identd as ident. Was meaning to do this for a while.

Actions #5

Updated by Robby K almost 5 years ago

I don't think 99% of users knows what a "ident" is, adding it as a major field would just cause more confusion, if I am adding it, it's gonna go to the Misc tab.

It was just an idea, in the Misc tab is also good.

mIRC for example does not have this issue, there it is done like this: whatever value you put in as the ident in the Identd settings is used as the ident in the USER command during login into IRC, even if Identd server is enabled or not, no matter if you use SASL authentication or not.

I think this is the right solution, an option to use the User id from Identd as ident. Was meaning to do this for a while.

This would be good indeed.

Actions #6

Updated by Per Amundsen over 4 years ago

As you can see in the screenshot, there are now two separate "username" fields, the first one acts as "ident nick", the second one is only for sasl/scram/challenge auth logins.

Additionally when there is no login username present, it supports username:password in the password field for sasl/scram/challenge auth logins.

There is also a new option in Options -> Server -> "Use username as ident nick", this option is now on by default and all identd requests matching a connection will reply with the server "Username" field set in the Serverlist, if for some reason there is no match, it uses the default "ident Nick".

It will be in the next beta, but I am not sure when that is gonna be, so I made this build you can test https://adiirc.com/build/1565867850/AdiIRC.exe, you can run that as is in a folder somewhere or replace your current AdiIRC.exe with this one.

Let me know if there are any problems.

Actions #7

Updated by Per Amundsen over 4 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF