nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-07-01 03:22:48 -05:00
Code Issues Projects Releases Wiki Activity

Add 'description' methods for Backend and Plug.

Browse Source 
These will typically be implemented by objects that are both a Backend
*and* a Plug, and the two methods will deliver the same results to any
caller, regardless of which facet of the object is known to that
caller.

Their purpose is to deliver a user-oriented natural-language
description of what network connection the object is handling, so that
it can appear in diagnostic messages.

The messages I specifically have in mind are going to appear in cases
where proxies require interactive authentication: when PuTTY prompts
interactively for a password, it will need to explain which *thing*
it's asking for the password for, and these descriptions are what it
will use to describe the thing in question.

Each backend is allowed to compose these messages however it thinks
best. In all cases at present, the description string is constructed
by the new centralised default_description() function, which takes a
host name and port number and combines them with the backend's display
name. But the SSH backend does things a bit differently, because it
uses the _logical_ host name (the one that goes with the SSH host key)
rather than the physical destination of the network connection. That
seems more appropriate when the question it's really helping the user
to answer is "What host am I supposed to be entering the password for?"

In this commit, no clients of the new methods are introduced. I have a
draft implementation of actually using it for the purpose I describe
above, but it needs polishing.
This commit is contained in:
Simon Tatham
2021-10-24 09:18:12 +01:00
parent 5374444879
commit f1746d69b1
9 changed files with 165 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
putty.h
View File

@ -680,6 +680,28 @@ struct BackendVtable {
* connections that would be lost if this one were terminated. */
char *(*close_warn_text)(Backend *be);
/*
* Returns a user-facing description of the nature of the network
* connection being made. Used in interactive proxy authentication
* to announce which connection attempt is now in control of the
* Seat.
*
* The idea is not just to be written in natural language, but to
* connect with the user's idea of _why_ they think some
* connection is being made. For example, instead of saying 'TCP
* connection to 123.45.67.89 port 22', you might say 'SSH
* connection to [logical host name for SSH host key purposes]'.
*
* This function pointer may be NULL, or may exist but return
* NULL, in which case no user-facing description is available.
* (Backends which are never proxied, such as pty and ConPTY, need
* not bother to fill this in.)
*
* If a non-NULL string is returned, it must be freed by the
* caller.
*/
char *(*description)(Backend *be);
/* 'id' is a machine-readable name for the backend, used in
* saved-session storage. 'displayname_tc' and 'displayname_lc'
* are human-readable names, one in title-case for config boxes,
@ -728,6 +750,11 @@ static inline void backend_unthrottle(Backend *be, size_t bufsize)
{ be->vt->unthrottle(be, bufsize); }
static inline int backend_cfg_info(Backend *be)
{ return be->vt->cfg_info(be); }
static inline char *backend_description(Backend *be)
{ return be->vt->description ? be->vt->description(be) : NULL; }
char *default_description(const BackendVtable *backvt,
const char *host, int port);
extern const struct BackendVtable *const backends[];
/*