WebApp authentication and authorization - up-to-date information?

[Rostislav Svoboda]

I have difficulties finding up-to-date information, tutorials, articles, blog posts etc. concerning WebApp authentication and authorization.

The most "recent" useful articles I found are from 2015 and 2014:

    https://rundis.github.io/blog/2015/buddy_auth_part2.html

    https://blog.knoldus.com/google-sign-in-using-clojure/

Uhm, my google-fu is getting weak... can anyone help please? Thanks

Bost

[z9znz]

This is what primarily keeps me from ever building a first (web) app with Clojure. 

Even the Web Development with Clojure, 3rd edition that I bought (beta) still does not have the section on this topic filled in.

I'm convinced that part of what prevents Clojure from being adopted more is the lack of a killer framework.  When I ask about this, the usual answer is that Clojure people don't like to be constrained and are happier to choose their own tools and libraries.  This is great if you already know what you're doing, but it's a vertical wall for newbies.

I admit I have not yet looked at Coast on Clojure - and perhaps it has the potential to be that entry point for newbies. 

But apropos to your question, perhaps the Coast docs on authentication will help you.  They illustrate using Buddy.  Buddy has not been updated since Q3 2017 (a fact I find discouraging), but perhaps it is still relevant.  https://github.com/coast-framework/coast/blob/master/docs/authentication.md

I keep dreaming of a Clojure-based starter system that includes authentication and some form of database interface (definitely need not be ORM; just a demonstrated pattern).  We could begin with that, and once we have a clue what's what, then we can go the usual Clojure route and hand select every library.

[Sean Corfield]

> some form of database interface (definitely need not be ORM; just a demonstrated pattern)

I'm curious as to what you feel is missing beyond clojure.java.jdbc / next.jdbc? SQL is the lingua franca for relational databases and those libraries provide the interface between Clojure data -- hash maps and vectors of hash maps -- and rows/resultsets.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/6d358084-de60-42a7-8893-a118a207bdab%40googlegroups.com.

--

Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Jérémie Grodziski]

Regarding the security part I find that delegating authentication and authorization to a specialized component is a good approach.

You can use Keycloak for that matter and I published some times ago some details about its integration in the Clojure world : https://github.com/jgrodziski/keycloak-clojure/tree/master/sample

Jérémie.

Le samedi 21 mars 2020 22:51:47 UTC+1, Sean Corfield a écrit :

> some form of database interface (definitely need not be ORM; just a demonstrated pattern)

I'm curious as to what you feel is missing beyond clojure.java.jdbc / next.jdbc? SQL is the lingua franca for relational databases and those libraries provide the interface between Clojure data -- hash maps and vectors of hash maps -- and rows/resultsets.

On Sat, Mar 21, 2020 at 2:30 PM z9znz <zedni...@gmail.com> wrote:

This is what primarily keeps me from ever building a first (web) app with Clojure. 

Even the Web Development with Clojure, 3rd edition that I bought (beta) still does not have the section on this topic filled in.

I'm convinced that part of what prevents Clojure from being adopted more is the lack of a killer framework.  When I ask about this, the usual answer is that Clojure people don't like to be constrained and are happier to choose their own tools and libraries.  This is great if you already know what you're doing, but it's a vertical wall for newbies.

I admit I have not yet looked at Coast on Clojure - and perhaps it has the potential to be that entry point for newbies. 

But apropos to your question, perhaps the Coast docs on authentication will help you.  They illustrate using Buddy.  Buddy has not been updated since Q3 2017 (a fact I find discouraging), but perhaps it is still relevant.  https://github.com/coast-framework/coast/blob/master/docs/authentication.md

I keep dreaming of a Clojure-based starter system that includes authentication and some form of database interface (definitely need not be ORM; just a demonstrated pattern).  We could begin with that, and once we have a clue what's what, then we can go the usual Clojure route and hand select every library.

On Saturday, March 21, 2020 at 8:29:04 PM UTC+1, Bost wrote:

I have difficulties finding up-to-date information, tutorials, articles, blog posts etc. concerning WebApp authentication and authorization.

The most "recent" useful articles I found are from 2015 and 2014:

    https://rundis.github.io/blog/2015/buddy_auth_part2.html

    https://blog.knoldus.com/google-sign-in-using-clojure/

Uhm, my google-fu is getting weak... can anyone help please? Thanks

Bost

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clo...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/6d358084-de60-42a7-8893-a118a207bdab%40googlegroups.com.

[z9znz]

This may sound like a rant, but it's not meant to be.  This is just my recurring frustration whenever I am led by my strong desire to use Clojure, but my typical use case is a basic business web app with authentication.  Such use case may not at all be the best use of Clojure, but it should be perfectly reasonable as Clojure is a powerful general purpose language.

It was not my intent to suggest that Clojure lacked a good solution to any particular need (authentication, data persistence, or anything else).  What is missing is a complete starter kit with _current_ instructions.

Every year or two I go looking for something like this, or at least a guide or tutorial.  And every time, I encounter at least one of the following:

 - A key element of the guide is outdated or depends on a library which is outdated (and where in some cases there is a reference made that everyone should switch to library Y, but then they're on their own to figure out how to use Y in this context)

 - One or more element of the simple app is not illustrated in complete detail, but the author points the reader to a tutorial for that element elsewhere... except that some of the guides use boot while some use lein while some use deps (which itself isn't necessarily a huge deal, but forces the beginner to start diving into build/dependency management tools rather than getting a first app built)

 - The guide doesn't cover a complete app

For whatever reason, searches for Clojure-related topics tend to (largely/only) turn up results that are 5+ years old.  That's an eternity in internet time.  Yes there are some great current libraries that probably do everything one might need, but still there are roadblocks which beginners will encounter where the answers are nonexistent or outdated. 

With respect to database interaction, I know of but haven't used Korma (which now appears to be dead?), HugSQL, and others.  Of course there's straight JDBC Java use (whereby I should just write my own thin JDBC wrappers like I did back in the Java Server Pages days...?).  <- If that's the answer, then I have no problem doing it; but I would suspect there's some other pattern that leverages some of the strengths of Clojure a bit more.  This one current example is basically useless: https://devcenter.heroku.com/articles/clojure-web-application .   It illustrates enough to show that Clojure can route and respond to http requests, and it can touch a database; but surely it is not an example of how people actually write Clojure web apps.

In contrast, there are numerous Django and Rails guides which illustrate the complete process of building a web app with their language+framework.  They even tend to include some amount of tests and even internationalization (as well as authentication, database interaction, and sometimes API/json cases).

Most of us don't get hired into Clojure companies, so any learning and doing is more of an evening/solo activity.  Probably many of us who have been exposed to Clojure really would love to use it in our day jobs.  But often the best way to get a new language or approach accepted is to build something useful and relevant to show the company.  That's how Java got into C++ shops and how Ruby got into Java shops.

Clojure will remain vital to some big companies regardless of whether the cost of entry is reduced; but sadly, the comparative abomination called JavaScript will continue to grow - eating the backend now too.  It could be Clojure/ClojureScript taking over the world.

On Saturday, March 21, 2020 at 10:51:47 PM UTC+1, Sean Corfield wrote:

> some form of database interface (definitely need not be ORM; just a demonstrated pattern)

I'm curious as to what you feel is missing beyond clojure.java.jdbc / next.jdbc? SQL is the lingua franca for relational databases and those libraries provide the interface between Clojure data -- hash maps and vectors of hash maps -- and rows/resultsets.

On Sat, Mar 21, 2020 at 2:30 PM z9znz <zedni...@gmail.com> wrote:

This is what primarily keeps me from ever building a first (web) app with Clojure. 

Even the Web Development with Clojure, 3rd edition that I bought (beta) still does not have the section on this topic filled in.

I'm convinced that part of what prevents Clojure from being adopted more is the lack of a killer framework.  When I ask about this, the usual answer is that Clojure people don't like to be constrained and are happier to choose their own tools and libraries.  This is great if you already know what you're doing, but it's a vertical wall for newbies.

I admit I have not yet looked at Coast on Clojure - and perhaps it has the potential to be that entry point for newbies. 

But apropos to your question, perhaps the Coast docs on authentication will help you.  They illustrate using Buddy.  Buddy has not been updated since Q3 2017 (a fact I find discouraging), but perhaps it is still relevant.  https://github.com/coast-framework/coast/blob/master/docs/authentication.md

I keep dreaming of a Clojure-based starter system that includes authentication and some form of database interface (definitely need not be ORM; just a demonstrated pattern).  We could begin with that, and once we have a clue what's what, then we can go the usual Clojure route and hand select every library.

On Saturday, March 21, 2020 at 8:29:04 PM UTC+1, Bost wrote:

I have difficulties finding up-to-date information, tutorials, articles, blog posts etc. concerning WebApp authentication and authorization.

The most "recent" useful articles I found are from 2015 and 2014:

    https://rundis.github.io/blog/2015/buddy_auth_part2.html

    https://blog.knoldus.com/google-sign-in-using-clojure/

Uhm, my google-fu is getting weak... can anyone help please? Thanks

Bost

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clo...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/6d358084-de60-42a7-8893-a118a207bdab%40googlegroups.com.

[Rostislav Svoboda]

> Every year or two I go looking for something like this, or at least a guide or tutorial.  And every time, I encounter at least one of the following:

>  - A key element of the guide is outdated or depends on a library which is outdated (and where in some cases there is a reference made that everyone should switch to library Y, but then they're on their own to figure out how to use Y in this context)

agree

>  - One or more element of the simple app is not illustrated in complete detail, but the author points the reader to a tutorial for that element elsewhere... except that some of the guides use boot while some use lein while some use deps (which itself isn't necessarily a huge deal, but forces the beginner to start diving into build/dependency management tools rather than getting a first app built)

agree

>  - The guide doesn't cover a complete app

agree

> For whatever reason, searches for Clojure-related topics tend to (largely/only) turn up results that are 5+ years old.  That's an eternity in internet time.  Yes there are some great current libraries that probably do everything one might need, but still there are roadblocks which beginners will encounter where the answers are nonexistent or outdated.

agree

> With respect to database interaction, I know of but haven't used Korma (which now appears to be dead?), HugSQL, and others.  Of course there's straight JDBC Java use (whereby I should just write my own thin JDBC wrappers like I did back in the Java Server Pages days...?).  <- If that's the answer, then I have no problem doing it; but I would suspect there's some other pattern that leverages some of the strengths of Clojure a bit more.  This one current example is basically useless: https://devcenter.heroku.com/articles/clojure-web-application .   It illustrates enough to show that Clojure can route and respond to http requests, and it can touch a database; but surely it is not an example of how people actually write Clojure web apps.

agree

> In contrast, there are numerous Django and Rails guides which illustrate the complete process of building a web app with their language+framework.  They even tend to include some amount of tests and even internationalization (as well as authentication, database interaction, and sometimes API/json cases).
>

> Most of us don't get hired into Clojure companies, so any learning and doing is more of an evening/solo activity.

agree. BTW it's 1 a.m. over here

It's 99% ... no, it's really like somebody's reading my mind and describing the my situation. Uff.

[Sean Corfield]

Yes, there is definitely a learning curve with Clojure and its ecosystem that makes it hard to just "dip in" every few years. It is not optimized for beginners and I don't think it ever will be (although the beginner experience is much better now than it used to be). It is not designed for "off-the-shelf" solutions (Django, Rails, etc). There are already plenty of technical solutions for those situations. That may be frustrating but that's the reality. Clojure isn't going to be mainstream and it's not going to take over the world. There are dozens of languages on the JVM and dozens of other languages. Some are already mainstream and will remain so. The rest will always remain niche. Again, as frustrating as that might be that's just reality.

A lot of people who come to Clojure do so precisely because it eschews the "batteries included" framework-heavy approach of some other technologies.

There are a lot of outdated tutorials, it's true. And a lot of libraries that were created years ago and then abandoned. Those were created by early adopters who were excited by Clojure but then moved on to another tech (or back to their previous tech). That's certainly very frustrating. It's pretty much impossible to modify those tutorials/libraries now to help folks who come across them, new to Clojure, and of course, we can't take them down either. Where we run across editable content, we can either make it better or add caveats on it being outdated, but that's a small segment of all that bad information.

clojure+u...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/4a7cfcb6-268e-4669-9230-896d77697120%40googlegroups.com.

[iamDecim]

I think this could be easily solved if some of the experienced users show more code.  I'm 100% sure a few of them could grab http-kit/pedestal/immutant and give an example of basic authentication and even making a simple post and throwing it up on github then advertising it via Twitter or reddit.  One weird issue which I've said a few times is a lot of people are using clojure but no one seems to like to make code/examples public.

[Matching Socks]

Dmitri Sotnikov's book "Web development with Clojure" includes an example.

Do not be put out by books or primers dated a few years back.  HTTP, Servlets, and Clojure have been quite stable.  Likewise the basic facts of authentication and authorization, right?  

On Saturday, March 21, 2020 at 3:29:04 PM UTC-4, Bost wrote:

[Sean Corfield]

Authentication is a serious business. Posting code examples for beginners to follow is likely to either be too complex to be a good example or too simple to be a good authentication process.

Also, I think a lot of "the experienced users" are building real-world apps that are proprietary in nature, especially around a sensitive topic such as authentication/authorization. We built our own OAuth 2 server-side stuff on top of Apache OLTS (which is very poorly documented) and it's both too complex to be a useful example -- an Auth Server, a Login Server, and a separate API Server that uses access/refresh tokens with the Auth Server -- and also includes proprietary logic that would be hard to detangle, even if the overall code was simple enough to serve as a useful example :( 

I found a lot of stuff about client-side OAuth 2 authentication -- which is the simplest part of the process and there are libraries out there for interacting with Twitter, Facebook, GitHub, and other OAuth 2/OpenID providers -- but there seemed to be almost nothing about writing the server-side stuff (and even when I found OLTS I pretty much had to work from the Java source code and the OAuth 2 RFC to figure it all out).

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/7dca94f3-b20c-4073-b2ee-0dbe3619f337%40googlegroups.com.

[Aleksandar Simic]

Hello

very interesting points raised and I think that they should be addressed.

On Sun, Mar 22, 2020 at 2:02 PM iamDecim <jburg...@gmail.com> wrote:

I think this could be easily solved if some of the experienced users show more code.  I'm 100% sure a few of them could grab http-kit/pedestal/immutant and give an example of basic authentication and even making a simple post and throwing it up on github then advertising it via Twitter or reddit. 

 

I was in two minds if I should do this, just due to time constraints. But you're right. So I'll commit to this here publicly.

If you don't hear from me with an example, please do bug/publicly shame me :)

It won't be a blog post, but it'll be a sample repo with a web app that allows you to:

- sign up

- confirm your email address

- sign in

- sign out

Time permitting, I'll add authorisation too for different roles.

One weird issue which I've said a few times is a lot of people are using clojure but no one seems to like to make code/examples public.

It's true.

But then again, this was recognised by some people and they've shared their apps/services online. For example this post on Reddit is very recent:

https://www.reddit.com/r/Clojure/comments/flvm5l/open_sourcing_rafiki/

Granted, it's not a type of the app that is being discussed here, but people do recognise this problem and are trying to do something about it.

- Aleksandar

[z9znz]

I very eagerly look forward to this, and thank you in advance.

[z9znz]

> But then again, this was recognised by some people and they've shared their apps/services online. For example this post on > Reddit is very recent:

> https://www.reddit.com/r/Clojure/comments/flvm5l/open_sourcing_rafiki/

This sent me to the blog post: https://medium.com/wefarm-product-and-tech/open-sourcing-rafiki-96483505fd8f , where I laughed loudly at the following:

 

[Gary Johnson]

Hi folks,

While it's not directly to your point, here is a pretty complete (IMHO) repository that I put together for getting you going with a new Clojure+Clojurescript website:

    https://gitlab.com/lambdatronic/clojure-webapp-template

Just clone it and check out the README.md file for a description of the build and runtime software requirements, build aliases, and expected usage in development and production modes. All of the build config files are built around the tools.deps clojure command-line interface and use a modern version of figwheel for development.

The deps.edn file contains aliases to:

1. Initialize a Postgresql database, including custom Clojure code that provides a simple "namespace"-like dependency system for your SQL files using a topo-sort procedure for dependency resolution. If you prefer to use a different database, you could easily tweak build_db.clj and create_db.sql to meet your needs.

2. Compile your CLJS code into app.js using advanced compilation settings (for production deployment).

3. Compile your CLJ code and launch an embedded Jetty web server on a port that you specify (or 8080 by default).

4. Launch Figwheel, compile your CLJS code into app.js using {optimizations :none} (for rapid development), launch an embedded Jetty web server on port 8080, and automatically hotload any live changes to your CLJS files into your browser session and live changes to CLJ files into your server (available on browser refresh).

In addition, the Clojure code provides a pre-configured middleware stack with custom middlewares for request and response logging, exception handling, and parsing EDN params in the request object. There is also simple routing-handler function using plain old Clojure with some helper function to render HTML and EDN/JSON responses that you can extend or replace to meet your objectives.

Super-cool features include a pre-configured system of routes, CLJ handlers, and asynchronous CLJS functions (using core.async) that allow you to trivially call SQL functions directly from Clojure (synchronously) and to call both CLJ and SQL functions from Clojurescript (asynchronously) using a similar calling syntax. All database interaction is done through Sean Corfield's excellent next.jdbc library.

In my usual programming model, I encode any operations that should happen in the database as SQL functions in Postgresql. These are loaded by my `clojure -A:build-db only-functions` alias. Then from Clojure, I can call these SQL functions like so:

```clojure

(call-sql "contact.get_user" user-id)

;;=> [{:name "Rich Hickey" :residence "Hammock"}]

```

Alternatively, I can call the same function from Clojurescript like so:

```clojure
(def my-contact (atom nil))

(go

  (reset! my-contact (<! (call-sql-async! "contact.get_user" user-id))))

;; At which point @my-contact now evaluates to:

;;=> [{:name "Rich Hickey" :residence "Hammock"}]
```

You can do the same thing with CLJ functions from CLJS like so:

```clojure

(def cool-result (atom nil))

(go

  (reset! cool-result (<! (call-clj-async! "my-cool-clojure-function" 1 2 3))))

;; At which point @cool-result now evaluates to whatever the result of calling (my-cool-clojure-function 1 2 3) on the webserver evalutes to.

```

NOTE: For security, only CLJ functions that are explicitly listed in remote_api.clj are allowed to respond to `call-clj-async!` requests from the browser.

Another pretty useful feature is a simple set of CLJS functions for storing arbitrary Clojure associative data (i.e. maps) in your browser's session storage:

- get-session-storage

- set-session-storage

- remove-session-storage

- clear-session-storage

The back-end code also includes a very simple `send-email` function implemented using `com.draines/postal` and a straightforward set of synchronously logging utility functions called `log` and `log-str` built using Clojure agents since using `println` and friends for back-end logging on a concurrent webserver is a recipe for unreadable spaghetti logs.

The front-end code is just a sparse skeleton using Reagent that provides a largely blank home page and an unstyled not found page. You can copy either page and use it as a template for adding any additional pages to your site. Note that the exported `init` method on each CLJS page receives the HTTP request params in JSON encoding as their first argument, so that you can easily respond to request parameters from the browser side of your application if you choose.

And last but not least, I've included a .dir-locals.el file in the toplevel of the repo that automatically configures your Emacs CIDER installation to seamlessly use the same figwheel settings as calling `clojure -A:figwheel` does. Magic!

Alright, folks. That's it from me for now. I hope some of you find this repository useful in your Clojure+Clojurescript web programming adventures.

Happy hacking!
  Gary

P.S. Specifically to your authentication point: The most straightforward and general place to implement authentication is in your middleware stack (handler.clj). Look for an existing Clojure library that provides an authentication middleware and add it at the level in the stack that you feel is most appropriate for your application. There are several of them out there.

Or...you could just be a maverick and roll your own. The fundamental operation of this middleware function is to grab some information from the request object and apply a strong test to it to determine if the next handler in the stack should be called or if an error response map should be returned. That's basically it. You can decide how best to design that authentication challenge based on your application's needs. Use encrypted passwords in your database, temporary user/session tokens, OAuth tokens, LDAP requests, or whatever else seems appropriate. If the test passes, call the next step handler from your authentication middleware. If it fails, return some kind of error response map with a meaningful status code (e.g., 403 Forbidden).

Another very useful option (which may be combined with middleware-level authentication) is to perform more find-grained route-level authentication at the level of the routing-handler function (handler.clj). Maybe your authentication middleware could attach a :role or :permission-level attribute to the request map before calling the next-step handler. Then in your routing-handler, you can check that attribute to determine if the authenticated user should be granted access to a particular route. If not, just return an error response map from your routing-handler function (again with something like a 403 Forbidden status code).

These are general suggestions for how to approach the authentication and authorization process within a Clojure web app. Other developers may (and probably do) have their own opinions on how to do it. As always, YMMV.

[z9znz]

Thanks very much for posting this and making the effort to document so well!

On Wednesday, March 25, 2020 at 2:04:56 AM UTC+1, Gary Johnson wrote:

Hi folks,

While it's not directly to your point, here is a pretty complete (IMHO) repository that I put together for getting you going with a new Clojure+Clojurescript website:

    https://gitlab.com/lambdatronic/clojure-webapp-template

Just clone it and check out the README.md file for a description of the build and runtime software requirements, build aliases, and expected usage in development and production modes. All of the build config files are built around the tools.deps clojure command-line interface and use a modern version of figwheel for development.

<snip>

[Aleksandar Simic]

On Mon, Mar 23, 2020 at 8:59 PM z9znz <zedni...@gmail.com> wrote:

I very eagerly look forward to this, and thank you in advance.

Here it is, it's very much rough & ready:

https://github.com/dotemacs/clojure-webapp

It does have authentication, but not authorisation.

So if you feel some things are missing, confusing or just unclear, please let me know via the GitHub's issues or my email and I'll try to help you out.

Before starting to create this sample app I figured "Oh, it'll be easy to just put it all together", but once you start doing it, you notice so many missing parts or things that should be done cleaner or in more detail. Maybe it's something that should be polished a bit more. If time allows it.

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/a9c44018-30a5-42ac-9200-c092cad91b1c%40googlegroups.com.

[z9znz]

Thank you, Aleksandar, for putting in this effort.  Now I know what I shall do with my weekend :).

On Thursday, March 26, 2020 at 4:40:40 PM UTC+1, Aleksandar Simic wrote:

On Mon, Mar 23, 2020 at 8:59 PM z9znz <zedni...@gmail.com> wrote:

I very eagerly look forward to this, and thank you in advance.

Here it is, it's very much rough & ready:

https://github.com/dotemacs/clojure-webapp

...