Deprecate Auth?

[jkarni]

The work we put into authentication was really useful in getting the internals right; and exposing an API made sense while nothing else existed. But now servant-auth exists and seems to me like the better solution. Can we deprecate the auth stuff in this repo, and start pointing people to servant-auth instead?

[alpmestan]

I'm a little bit bothered by the fact that authentication is a key topic, so much that it's covered in the tutorial, but you're suggesting to move it all to non-core packages. I want auth to be documented in the tutorial, whichever package it ends up being implemented in. servant-auth's README and the tutorial hold different standards wrt depth of explanation, obviously, so I do not want for the go to auth solution to be underdocumented. It'd have to be covered in the tutorial, in reasonable depth.

It might require a little bit of work but nothing too scary, so yes from me pending the changes that I suggest.

[alpmestan]

There's also the issue of maintenance. Would the auth packages move under the haskell-servant org? If not, what kind of maintenance/development/collaboration scheme would be in place?

[jkarni]

I agree with the tutorial needing to be updated; I'd be happy to do it. I can check whether we can move 'servant-auth' to the 'haskell-servant' organization.

…

On Wed, Sep 13, 2017 at 04:34:37PM +0000, Alp Mestanogullari wrote: I'm a little bit bothered by the fact that authentication is a key topic, so much that it's covered in the tutorial, but you're suggesting to move it _all_ to non-core packages. I _want_ auth to be documented in the tutorial, whichever package it ends up being implemented in. servant-auth's README and the tutorial hold different standards wrt depth of explanation, obviously, so I do not want for the go to auth solution to be underdocumented. It'd have to be covered in the tutorial, in reasonable depth. So yeah, it might require a little bit of work but nothing too scary, so yes from me pending the changes that I suggest. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #805 (comment)

[alpmestan]

The motivation for my question is that there are going to be changes that break servant-auth, and since auth is too important to be left broken for a few days or weeks, we need to make sure we'll be able to get the necesary changes in and probably have releases happen together (at least for those scenarios, not for minor updates to core servant packages or auth that don't affect anyone else, of course).

[3noch]

The motivation for my question is that there are going to be changes that break servant-auth, and since auth is too important to leave broken for a bit

I agree. However, this cuts both ways. Because it's so important you may want to make it one of the official servant libraries. But also, because its so important, if a new release of servant does not work with servant-auth, you can be very sure that people will get it fixed quickly. Until they do, they'll have to use an older version of servant. That scenario is pretty common in package management and doesn't scare me in the slightest.

[alpmestan]

@3noch I'd be in favor of having them as core packages (but just not in the standard ones), but it's not my call =) You make good points. My main request is really to have a detailed and very, very approachable section in the tutorial, like the other sections of it. The rest is just about us trying to make sure both package sets will work well together, hand in hand.

[3noch]

@alpmestan You're right about documentation though. That is crucial and it definitely needs to cover auth. I don't care where the package lives, myself. As long as it's easily discoverable by servant neophytes.

[phadej]

From my "release-manager" POV, having servant-auth as a core package is 👍. There is no additional work. I (did/will) check how servant-auth compiles during preparation for servant releases, as it's good sanity test (among others).

In fact, servant-auth was GHC-8.2.1/servant-0.11 ready at the moment servant-0.11 was released. It was only pending release of external dependencies. And releasing all at once (i.e. major servant, minor servant-auth updates) is less context switching.

So overall, 👍 to moving servant-auth to haskell-servant organisation.

[aaronlevin]

As the creator of this mess, I'm supportive 👍 :)

I wouldn't worry about breaking changes. We made the Experimental module for a reason.

[roberth]

I have accidentally used this module in a new project. I have switched to servant-auth because it supports optional authentication. Please remove this module. This is "Bad UX" ;)

[alpmestan]

This supports optional authentication too, I think? Also, we need a little bit of a migration guide, as there are dozens of projects out there using the auth module from the core packages.

[roberth]

Ah, yes, I though the parameter had to be WithMetadata a where a is some kind of proof of authentication, but that's only in servant-auth-cookie. This is a servant issue and the servant interface seems very unconstraining indeed.

A migration guide is a good idea. In the meanwhile you could move this module into another package, but that seems like too much effort. I think updating the servant tutorial is a good start.

[alpmestan]

Right, I think this would be a reasonable plan to migrate the auth stuffs:

• (if Plow Technologies agrees) move servant-auth-* into core packages or get them under the servant org or keep it where it is but make sure we'll be able to sync up as regularly as needed for releases, breaking changes and all that.
• rewrite the auth bit of the tutorial to explain how to use servant-auth, including any instructions about adding dependencies (in case servant-auth-* is not merged in the core packages) etc
• maybe include a small migration guide that shows how to switch something that uses the .Experimenta.Auth over to servant-auth, at least for another major release or two.
• pull the trigger.

[dbaynard]

I'm in the process of setting up a server using servant-auth. I'd be happy to contribute to the tutorial, say.

It would be very helpful to have a (referenced) list of the security features within the docs, not least because it shows those of you who have designed the libraries have considered them.

[jkarni]

Just got the go-ahead from Plow. I'll move the repo today.

@dbaynard I agree. There are other things to do as well, before officially deprecating servants current auth. I'll start an issue keeping track of those in the repo, once I move it over.

[domenkozar]

Talking to @phadej and @alpmestan, here's a straw-man proposal:

1. Cleanup phase

• deprecate Servant.API.Experimental.Auth
• deprecated old and bring documentation in servant-auth on-pair with servant standards using Sphinx

2. Merger phase

• move Servant.Auth.Auth and Servant.Auth.BasicAuth to Servant.API.Auth
• make sure the new BasicAuth has feature parity with Servant.API.BasicAuth
  Then all of the rest of authentication schemes would stay in servant-auth.

Open questions:

• servant-auth-client shouldn't depend on http-client due to ghcjs