My nick is not set and I'm not identified with nickserv automatically when reconnecting to a server using the /server command after being disconnected if I have those options set for the network

ekolis commented 8 years ago

Expected behavior

My nick is set again (ghosting my old one if necessary) and I'm reidentified with nickserv

Actual behavior

Nothing happens unless my original nick is still available; I get an ~~autogenerated~~ alternate (configured previously) nick if my original is in use and needs to be ghosted (or a random one if the server is configured that way), and I'm not identified with nickserv, even if my original nick is available.

Steps to reproduce the issue

Set custom nick and password for an IRC network
Connect to that server automatically on startup or with the network/server/channel dialogs; my nick is set and I'm identified with nickserv
Disconnect from the network
Reconnect using the /server command
System information

KVIrc 4.9.2 'Aria'

Runtime Info: System name: Windows Release : 6.2.9200 System version: Windows 8 Professional (x64) (Build 9200) Architecture: Intel64 Family 6 Model 37 Stepping 5 Qt version: 5.5.1 Qt theme: windowsvista

Build Info: Build date: 2016-07-06 02:13:19 UTC Sources date: 20160706 Revision number: git-6779-g96e790b System name: Windows-6.3.9600 CPU name: AMD64 Build command: C:/Program Files (x86)/CMake/bin/cmake.exe Build flags: MANDIR=share/man CMAKE_INSTALL_PREFIX=C:/projects/kvirc/build/release Threads=Win32 Compiler name: C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/cl.exe Compiler flags: /DWIN32 /D_WINDOWS /W3 /GR /EHsc Qt version: 5.5.1 Features: IRC, IPv6, Crypt, SSL, IPC, Transparency, Webkit, Perl, Python, Enchant, Qt5, KVS

(My CPU is listed as AMD64 but it's actually a rather old Intel Core i3; is this a mistake?)

wodim commented 8 years ago

(My CPU is listed as AMD64 but it's actually a rather old Intel Core i3; is this a mistake?)

No, that's the CPU of the computer that was used to build the client.

AndrioCelos commented 8 years ago

Does the Attempting connection line in the console show the correct network name?

ekolis commented 8 years ago

No, that's the CPU of the computer that was used to build the client.

Ah, I see, it was a bit confusing since there are separate sections for runtime and build information that I hadn't noticed. I think the OS version under runtime info is incorrect, though; I'm actually running Windows 10 rather than Windows 8. Pretty sure I already filed an issue for that already!

Does the Attempting connection line in the console show the correct network name?

It seems to; for instance I see "Attempting connection to irc.snoonet.org (Snoonet) on port 6667" when I connect to the Snoonet network/server I configured.

Speaking of Snoonet, perhaps this should be added to the built-in network list you can choose from? It's got pretty much everything else under the sun already!

staticfox commented 8 years ago

I think the OS version under runtime info is incorrect, though; I'm actually running Windows 10 rather than Windows 8. Pretty sure I already filed an issue for that already!

This was fixed in b79e1f031849a82dfaa69c10e01697b9a8f866bf

un1versal commented 8 years ago

Your KVIrc build is quite old now, from 6th July?! One of your complaints has been addressed already (at least). Update your KVIrc build and retest again.

Ghosting isnt done automatically afaik and I dont think it should. Some networks also offer nick protection and when this is set, sometimes you need to release the nick before the original nick becomes available for re-identifing again, this should not be done automatically imo.

@AndrioCelos I dont think this is a bug, nick ghosting and releasing nick protection (the latter when IRCD has been set by user with enforce or secure on) should not be done by client automatically as ekolis seems to be suggesting.

AndrioCelos commented 8 years ago

Was @ekolis trying to use a different nickname for a specific network?

ekolis commented 8 years ago

@un1versal Sorry, I think I downloaded a more recent version but then deleted the installer because the version number was still 4.9.2 so I thought I'd already installed one not too long ago! I should probably go ahead and update...

Why do you think ghosting yourself shouldn't be automatic? I think it would be a quite useful feature. Could it be abused somehow? You can't ghost someone else if you don't know their password; do they get spammed with warnings if you try?

I'm not sure what you mean by "nick protection"; do you mean the thing that snoonet does where it assigns you a random numbered nick (such as "snoo42069") if you don't identify?

@AndrioCelos I was trying to use a specific name for at least one network, yes; I thought the global username I'd set wasn't taking effect for some reason, but it looks like it had just been reset like most of my other preferences at some point; I thought it was due to updating the app, but if I'm using such an old build, maybe it was something else?

AndrioCelos commented 8 years ago

On some networks, once services forces an unidentified user off a nickname, there is some mechanism that prevents other users from logging in with that nickname at all. The owner would need to use a NickServ command to release it, or wait.

ekolis commented 8 years ago

@AndrioCelos That seems rather draconian... just because I forget to identify, don't notice the message that I need to do so, or don't register quickly enough, I'm locked out of using that username for hours/days/forever?

un1versal commented 8 years ago

if you have set enforce on you can release that temporarily for immediate nick availability.

ekolis commented 8 years ago

@un1versal I suppose if you were an op (or whoever has such privileges) you could do that, but good luck to anyone trying to get them to do that...

AndrioCelos commented 8 years ago

Actually, that command is available to everyone.

ekolis commented 8 years ago

@AndrioCelos That seems like an... exploit, or something? What's the point of having a lock on your username if it's so easily disabled?

Anyway, sorry for turning this issue into a tutorial on IRC features!

un1versal commented 8 years ago

Such protections are in place or are put in place by a nick owner to prevent other users from using the previously registered nick without being identified to it and pretending to be someone else (potentially). The only exploit here is in your imagination.

If you wish to make a feature request to have Ghosting done automatically or whatever, I think that would possibly be misused somehow so I disagree with that unless it can be proven it has no potential for misuse.

You should look for help with your server in their respective channels if you need help with some specific server, you can script most of these things anyway and use it to workaround your perceived problems.

ekolis commented 8 years ago

OK, sorry for the trouble, then! I must have misunderstood what you meant by nick protection - I thought you were talking about nicks in general being protected, not just registered ones.

IceN9ne commented 5 years ago

Are you using /server -l to reconnect? Also, what is the full command you use to reconnect?

ekolis commented 5 years ago

It's been a while but I think I'm just using /server irc.freenode.org or something like that.

IceN9ne commented 5 years ago

Ok, then it's working as expected. By specifying a server address, you're essentially reusing a dead IRC context and starting an all-new session that has no relation to the previous session in that context. Use /server -l to reconnect using the last connection data that was used in that context.

About the method you were attempting, depending on the server string you pass, it may be creating what is called a "Standalone Server", which won't use your network settings, but will fall back to your global settings. When a Standalone Server is created, you'll see the server added to a network in the list aptly called "Standalone Server".

kvirc / KVIrc