Summer of Code Haskell Submissions?

[erewok]

Hi All,

I was wondering if anyone is interested in submitting any Servant projects for Google Summer of Code. I would love to see Servant continue to improve as an enterprise-ready web framework, but unfortunately there's only enough volunteer time to go around, so if you all are interested, perhaps we can use an issue like this to talk about improvements worth pitching? Also, it looks like there was a [submission earlier this year?]#463 (comment)).

Here are the things that leap to mind for me:

• Support Oauth1 in Servant/Servant-auth (maybe already supported and I don't realize...?). Oauth1 is still commonly used for server-to-server applications, such as the Twitter API.
• Support Oauth2 in Servant/Servant-auth (there's an OpenID Connect cookbook PR open, so I'm probably behind on this one).
• Any other ideas...?

If servant-devs think it's a good idea, perhaps there's someone who will step forward (with experience in previous years) to craft the submission?

[alpmestan]

See #880 for the 2018 edition, which can serve as inspiration. I'd be happy to help craft and later mentor servant projects in general. Perhaps some ideas that are worth mentionning (I can expand later, I have to run in a bit):

• Drive Re-engineer Verb #841 home
• Extract a backend-agnostic "router generator" out of servant-server, similarly to how we turned servant-client into servant-client-core (http client lib agnostic, lets us support ghcjs) and servant-client (http-client "backend"). This would make it as simple as it can be to write tooling that can inspect, debug and transform the routers generated for given API types or even to target other web servers than warp.
• Make servant-auth "open" in the auth schemes that it supports and implement some. Right now, unlike the rest of the servant world, servant-auth won't let you define your own auth scheme and use it just like you'd use servant-auth out-of-the-box support for basic auth or jwt. This would "replace" your suggestions, or perhaps rather augment them with a "0th step".

The second one is something I've been eyeing on and off for quite some time but for which I haven't quite managed to have both the motivation and the time simultaneously at any given moment.

[erewok]

@alpmestan: I like your suggestions better than mine.

[erewok]

How's about this, from your third suggestion @alpmestan and based on the previous submission here.

---
title: Make servant-auth "open" for defining custom auth schemas
---

Since its introduction in 2017, the 
[servant-auth](https://github.com/haskell-servant/servant-auth)
package has seen uptake in the 
Servant[servant](https://haskell-servant.readthedocs.io/) community
but unlike the rest of the Servant ecosystem, `servant-auth` won't 
let you define your own auth schemas and use them just like you'd use 
`servant-auth`'s out-of-the-box support for *basic auth* or JWT. Indeed, 
users have shown interest in Oauth1 and Oauth2 (and, related, 
OpenIDConnect) in the Servant family of libraries, so if `servant-auth` 
were open, it should be more straightforward to integrate these and other 
auth schemas for Servant servers, clients, API documentation, and other 
places. 

Thus, a potential project could be to open up `servant-auth` and then 
implement Oauth1 or another authorization schema as an example of how 
to use the new functionality for the project. The end goal of this project 
would be to increase the flexibility and freedom end-users have to implement 
auth schemas in `servant-auth`, with reasonable haddocks, and some tests 
as well. 

The student could optionally also (co-?)author [cookbook recipes](https://haskell-servant.readthedocs.io/en/stable/cookbook/index.html)
illustrating how to serve or query APIs that are protected by the newly supported 
authentication schemes, or on how to implement new auth schemas using the 
new functionality made available in `servant-auth`, therefore making the student's 
work easily discoverable by current and future servant users. 

By the end of the summer, _servant-auth_ would move closer to its goal of being 
_the_ definitive auth solution for Servant.

 **Mentors**: Alp Mestanogullari

 **Difficulty**: Intermediate

[alpmestan]

@erewok Looks great! This can be submitted as-is, as far as I'm concerned.

[erewok]

Alright. I'll submit it. Thanks for reviewing.

[erewok]

@alpmestan, I added a PR to summer-of-haskell, but I may need your help with any detailed questions beyond my knowledge of servant-auth, so please keep an eye on the discussion there. Thanks again.

[alpmestan]

@erewok I'm subscribing to that issue then. Thanks a lot for taking care of this!

[erewok]

They actually merged it already.

You're welcome. I just want to help however I can because I appreciate the work you all put into Servant.