|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
Excellent idea. I had already suggested that but they would not listen. I don't think it is fair to suggest that Khaled has not been listening. But the diversity of suggestions is great!!
|
|
|
|
Joined: Dec 2002
Posts: 5,477
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,477 |
So I think you should put the NickServ text in several languages in the mIRC database. This is something that I am completely against, for reasons that I have already explained in my previous posts. I will not make such a feature work based on checking for specific words in an event. Implementing a feature in this way is worse than using a server version number to decide whether to enable certain client features, which is what numeric 005 was meant to resolve. The current issue is due to this feature being badly implemented on the server side. The server coders implementing this should have realized that clients need to have a clear way of detecting events like this, as opposed to requiring clients to implement hacks that can break across languages, ircds, ircd versions, and so on.
|
|
|
|
Joined: Dec 2002
Posts: 5,477
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,477 |
Why don't you do something more clever?
As most (about 90%) of services when you identify you get "+r" usermode, you can start auto-join if you receive that usermode flag instead of NOTICE from nickserv that if i use an other services language non-english it may be broken. Raccoon pointed out that there are several different usermode +r alternatives, so mIRC would in that case have to cater for multiple different representations of usermode +r based on server version numbers.
|
|
|
|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
I agree with Khaled about not coding something that has to detect different language strings or which uses e.g. modes which are not standardised. But as posted in a comment above, I believe that this can be coded without either of these based only on: 1. User's mIRC Server settings for automated authentication; 2. Use of Nickserv response strings which are NOT language specific (like "/msg Nickserv" which are IRC commands and don't differ between languages) to identify Notices from Nickserv that should be ignored. 3. Assuming that user's mIRC server settings are correct and server is working correctly (which will be true 99.9% of the time) and so user will be authenticated ok and assuming that Nickserv notices not ignored by 2. are confirming authentication - but handling with a lengthy timeout the situation when this is not the case. (If Notice is a failed authentication, then we should still attempt a /join.) With this approach you will not need to code for: - Language strings
- User modes
|
|
|
|
Joined: Dec 2002
Posts: 5,477
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,477 |
So, the only method that will work for now, that is language-independent, seems to be:
1) After the MOTD is received, check incoming notices from "nickserv". 2) Ignore the notices if they contain "/msg" or "/nickserv". 3) Otherwise, assume it is a notice indicating success or failure of nickname identification, so trigger perform. 4) If no such notice is received after 60 seconds, trigger perform.
However, this will fail if an ircd changes the text in notices eg. there is no reason why a server could not say "visit this website" or "join this channel" to learn how to register/identify your nickname, instead of specifying /msg or /nickserv. This will also fail if nickserv sends any other notices eg. it could send notices informing users of other features or recent developments.
This change will be in the next beta.
|
|
|
|
Joined: Dec 2002
Posts: 2,033
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,033 |
IMO all of that would be a mistake. The suggestion of the three second delay should work fine.
Perform finishes > 3 second delay > Autojoin.
All of this other stuff of waiting for NickServ and +r mode is what scripts are for.
Just my 2 cents.
Last edited by RoCk; 30/09/18 08:21 PM.
|
|
|
|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
RoCk - in my experience (with 45+ years programming experience) any solution as simple as waiting for 3s will only work the majority of the time - maybe even most of the time.
But there is only one thing worse than something which doesn't work - and that is something that mostly works but sometimes doesn't. Intermittent problems are the worst type by far, because the cause can be incredibly difficult to work out.
And a simplistic solution that waits only 3s would have a significant number of intermittent failures. For example, I would think it highly likely to fail when a netsplit had occurred and hundreds of IRC clients were automatically logging in and authenticating at the same time.
To handle this, you have to increase the timeout substantially to cope with those (say) 10% of situations where it takes >3s, but that means all the automated joins have to wait for that period - and then the functionality becomes useless because people will turn it off.
So you need a deterministic solution which copes with hiccups but doesn't delay the autojoins - and the proposed solution is the simplest we have come up with so far which does that.
|
|
|
|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
Khaled - I think you are being a little pessimistic here (though that is of course your job as designer/coder).
We are only talking about user settings for a server where they want mIRC to authenticate for them (as opposed to i.e. using perform or a script). You would only use this if the server supports /msg nickserv, /nickserv or SASL. (So e.g. Undernet X is NOT supported.)
It is possible that Nickserv may have been changed on a particular IRC network to do something non-standard, but that would be ... well, non-standard and so mIRC should not be expected to handle it.
So, providing that you only look at notices from nickserv (and not from any other services which might advertise before authentication), and providing that you check for "/msg nickserv" and / or "/nickserv" (which are what mIRC uses - so let's not check for anything wider), and providing that nickserv sends a notice for success or failure of authentication (i.e. doesn't not say anything), then this should work pretty reliably IMO.
I would also suggest that if 4. happens, then mIRC should put some sort of explanation up in the status window so as to prompt the user to fix the configuration (by e.g. switching to perform or a script).
P.S. My testing showed that SASL 903 response came much earlier in the connection than nickserv, but I am unclear whether that is because SASL is synchronous or just because it is significantly faster. If SASL is synchronous authentication (as opposed to nickserv which is asynchronous) then we don't need something similar to this proposal for SASL - but if SASL is asynchronous then we probably need the same sort of solution. The SASL specs should be able to clarify this.
|
|
|
|
Joined: Jul 2014
Posts: 329
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Jul 2014
Posts: 329 |
However, if you are looking for a simpler solution and I believe it is effective and that it minimizes this problem to all users on any network, then you have to create an option in the mIRC Favorites dialog that allows you to customize the time of entry into the channels when we do the network connection.
TECO irc.PTirc.org (Co-Admin)
|
|
|
|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
However, if you are looking for a simpler solution and I believe it is effective and that it minimizes this problem to all users on any network, then you have to create an option in the mIRC Favorites dialog that allows you to customize the time of entry into the channels when we do the network connection. You have missed the point of my previous email - if you work only on a timer there is NO single timer value that gives you a prompt autojoin and which works reliably when nickserv is running slowly. You need a deterministic solution.
|
|
|
|
Joined: Dec 2002
Posts: 2,033
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,033 |
He already stated that this issue is caused by the bad implementation of a feature on server side, should he add a workaround (hack) for every dumb little thing some server adds? The 3 second delay was workaround enough, make it 10 seconds if that's what it takes. If the delay solution is overly simple, then the other solutions mentioned before are way overly complicated.
|
|
|
|
Joined: Dec 2002
Posts: 2,033
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,033 |
A scripted solution is what's needed.
|
|
|
|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
He already stated that this issue is caused by the bad implementation of a feature on server side, should he add a workaround (hack) for every dumb little thing some server adds? The 3 second delay was workaround enough, make it 10 seconds if that's what it takes. If the delay solution is overly simple, then the other solutions mentioned before are way overly complicated. IRC is full of badly implemented features. That is real life. But this is not (really) one of them - nickserv is asynchronous - which is a reasonable thing if you want people to be able to start off unauthorised and then authorise at a later date. (SASL by comparison assumes you authorise at connect time.) When you have an async service, you need to have functionality that takes that into account. Yes - we could have a fully scripted solution and not have mIRC provide any nickserv authentication functionality - and then expect every user to write the script necessary. But Khaled chose to provide nickserv asynchronous authentication , so this is fixing up an issue with it properly.
|
|
|
|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
Or in other words, Khaled is going to create a proper solution not a Kludge which will fail intermittently and create a support headache.
|
|
|
|
Joined: Dec 2002
Posts: 5,477
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,477 |
I think you are being a little pessimistic here It is called experience :-) As I mentioned, mIRC already needs to check for specific strings in certain numerics due to those numerics being used for different features on different ircds. These have had to be updated several times already. Unfortunately, it takes a long time for someone to notice that mIRC's behaviour has changed due to an ircd changing wording in a numeric - especially if the change in behaviour is subtle. In the meantime, mIRC would actually be doing the wrong thing in such a situation. Depending on words in a server message along with the order of server events is not a reliable, long-term solution.
|
|
|
|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
I think you are being a little pessimistic here It is called experience :-) As I said, pessimism is part of the job - exactly for the reasons you describe.
|
|
|
|
|