Mailing-List: contact dev-help@mina.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mina.apache.org
Received-SPF: pass (athena.apache.org: domain of sop@google.com designates
 216.239.45.13 as permitted sender)
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:in-reply-to:references:from:date:message-id:
	subject:to:content-type:content-transfer-encoding:x-system-of-record;
	b=YxV3dgsvC+TRU40IPjYJvT9FykbOWWS2pWTvm2TG9y+i1NlDUuz//1rXJxPKAWaGw
	SoT/Zee41tx0HkcgZAGcg==
MIME-Version: 1.0
In-Reply-To: <b23ecedc0911130908q23f52ddp1eeab1930bcb6331@mail.gmail.com>
References: <4AEB3E2A.8070906@fifthhorseman.net>
 <1cc472780911130700j200442dr692825f67eedbc90@mail.gmail.com>
	<b23ecedc0911130908q23f52ddp1eeab1930bcb6331@mail.gmail.com>
From: Shawn Pearce <sop@google.com>
Date: Fri, 13 Nov 2009 09:28:18 -0800
Message-ID: <1cc472780911130928h2933158chd26ecc7649f81d84@mail.gmail.com>
Subject: Re: symmetry of pluggable authentication classes?
To: dev@mina.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 13, 2009 at 09:08, Guillaume Nodet <gnodet@gmail.com> wrote:
> Yeah, it may make more sense to always return a boolean then. =A0Wdyt ?

I think boolean makes more sense as a return, its the result of the
authentication operation, "true" they are permitted, "false" they are
not.  If the authenticator cares about attaching more than the
username to the session for downstream usage, its got the session
available to do that with an Attribute.  If it doesn't, it can happily
ignore the whole mess and simply return its status.

Returning Object is a bit sloppy, we are overloading null to mean "I
hate you go away", and the return type isn't type safe.  E.g. its easy
to make your PasswordAuthenticator return a different type of user
data than your PublicKeyAuthenticator, and downstream get surprised
when one type of authentication results in an unexpected
ClassCastException.  The Attribute stuff on ServerSession tries to
reduce the chances of that sort of runtime surprise.  (Though it does
nothing to ensure both authenticators actually populated the
Attributes your downstream code cares about.)

> Btw, I've done quite a bit of refactoring on the shell / commands
> interfaces, so it will break any existing app (though the changes are
> quite easy to do).

Yea, I've noticed.  Shouldn't take me long to update, I just haven't
had the time to pick up a newer snapshot from trunk.  Minor API
breakages are an accepted risk for using a project still under active
development.  :-)