[erlang-questions] detecting ssh auth failures

[Daniel Goertzen]

> I guess that you would prefer to get, for example, an integer or atom as
> error reason. Correct?


That's right.

I like the tuple solution because then I wouldn't have to include the record
definition.  Furthermore, I would prefer an atom instead of a macro for the
same reason.



> #ssh_msg_disconnect{code = ?SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED,
>                    description = "Protocol version " ++  StrVsn
>                                  ++ " not supported",
>                    language = "en"},



This still has some limitations.  What if I'm making a GUI app in Spanish
and I wanted to display the unsupported version in a dialog box?  Something
like the following would be more flexible...

{error, {ssh_disconnect_protocol_version_not_supported, StrVsn}}

... and more consistent with the way other parts of OTP work (tcp, ssl).


But I'm making a mountain out of a molehill. :)   I really only need to
separate auth errors from other kinds of errors.  Any of your ideas would
help.

Dan.



On Thu, May 26, 2011 at 10:09 AM, Niclas Eklund <nick@REDACTED>wrote:

>
> Hi!
>
> I guess that you would prefer to get, for example, an integer or atom as
> error reason. Correct? I.e. so you could match on the case when you get
> "Unable to connect using the available authentication methods". In this case
> the generated message is (the macro represents an integer):
>
> #ssh_msg_disconnect{code = ?SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE,
>                    description = "Unable to connect using the available"
>                                  " authentication methods",
>                    language = "en"},
>
> But in some cases it contain additional information. E.g.
>
> #ssh_msg_disconnect{code = ?SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED,
>                    description = "Protocol version " ++  StrVsn
>                                  ++ " not supported",
>                    language = "en"},
>
> In the latter the description reveals more details. Perhaps the error
> messages could have been a 3 tuple:
>
>  {error, Code, Description}
>
> instead of what's normally used {error, Reason}. Changing the return value
> would break existing code (applications using SSH), which wouldn't be very
> popular ;-) Perhaps a configuration parameter could be used to control this
> (the default behaviour should as it is) ....
>
> Best Regards,
>
> Niclas @ Erlang/OTP
>
>
> On Tue, 10 May 2011, Daniel Goertzen wrote:
>
>  I am using ssh to automatically connect and operate a remote device.  I'd
>> like to distinguish authentication failures from other kinds of failures.
>> Currently I will get this as an auth failure from ssh:connect():
>>
>> {error,"Unable to connect using the available authentication methods"}
>>
>> Now I could include that error string in a pattern to detect an auth
>> failure, but it feels rather brittle (ie, what if someone changes the
>> wording).  Is there a better way to do it?  Is this an API design bug?
>>
>> Regards,
>> Dan.
>>
>>
>
>


-- 
Daniel Goertzen
-----------------
dang@REDACTED (work)
daniel.goertzen@REDACTED (home)
-----------------
1 204 272 6149 (home/office)
1 204 470 8360 (mobile)
-----------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110527/e680c850/attachment.htm>