From felipe.lessa at gmail.com  Sat Jan  2 03:27:34 2016
From: felipe.lessa at gmail.com (Felipe Lessa)
Date: Sat, 2 Jan 2016 01:27:34 -0200
Subject: [web-devel] Announcing serversession
Message-ID: <568743A6.50008@gmail.com>

Hey!

These packages have been available for a while but only now I've finally
publicly announced their availability.  Please see my blog post at
http://blog.felipe.lessa.nom.br/?p=153, but feel free to reply back here.

Happy New Year!

-- 
Felipe.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/web-devel/attachments/20160102/d8f6448f/attachment.sig>

From jeremy at n-heptane.com  Tue Feb  9 17:46:38 2016
From: jeremy at n-heptane.com (Jeremy Shaw)
Date: Tue, 9 Feb 2016 11:46:38 -0600
Subject: [web-devel] path to sendmail
Message-ID: <CAGE_JKYFJgWtzRTeDCwbdjNN-1o-n9ReftoFGVP=uCuArKJccg@mail.gmail.com>

Hello,

I have a web application which needs to send mail using sendmail.

However, the way the system is configured, sendmail is not in the web
server's $PATH.

There are two fixes for this -- change the init script so that sendmail is
in the $PATH -- or modify the web server so that the admin can set the path
to sendmail via the control panel.

At first the second option sounds good. But I wonder about the security
implications. If someone manages to get the password for the admin control
panel -- they could change the path to sendmail to something else -- like
`vim` or `gcc` and then somehow craft a message that would place a backdoor
on the system.

Now, given that the input to the message is going to be a mime message that
sounds pretty difficult. But, then again, in December tons of Joomla sites
were open to an exploit where a malformed user-agent header allowed hackers
to execute arbitrary code.

Although in this case I care about sendmail, this is clearly an issue for
any web application that depends on external binaries like pandoc, etc.

In my use case, I am dealing with a CMS and I assume the poor user doesn't
know anything about Haskell, init scripts, ssh, etc. So, allowing the
location to be changed via the admin panel makes things easier because it
can be adapted to any distribution. (Clearly, I would start by checking the
most common locations, but provide an escape hatch for oddballs).

But I don't like the idea of providing a potential attack vector.

Any thoughts ?

- jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/web-devel/attachments/20160209/d3a6cd51/attachment.html>

From michael at snoyman.com  Tue Feb  9 17:55:16 2016
From: michael at snoyman.com (Michael Snoyman)
Date: Tue, 9 Feb 2016 19:55:16 +0200
Subject: [web-devel] path to sendmail
In-Reply-To: <CAGE_JKYFJgWtzRTeDCwbdjNN-1o-n9ReftoFGVP=uCuArKJccg@mail.gmail.com>
References: <CAGE_JKYFJgWtzRTeDCwbdjNN-1o-n9ReftoFGVP=uCuArKJccg@mail.gmail.com>
Message-ID: <CAKA2Jg+dvJ+pFUCtae+qYy6c7CXnEOV9Mychko+vV4gqfOM9sg@mail.gmail.com>

Two thoughts come to mind:

* Hard-code into the application a list of common sendmail locations and
search them
* Allow some kind of configuration (via file, env var, etc) to specify
sendmail location at launch

The first may sound slightly dangerous, but if you're already searching the
PATH for `sendmail`-named binaries, I don't think it's any worse. I'd
definitely include a configuration override to set the location of the
sendmail executable and override any searching (via list of paths or the
PATH var).

On Tue, Feb 9, 2016 at 7:46 PM, Jeremy Shaw <jeremy at n-heptane.com> wrote:

> Hello,
>
> I have a web application which needs to send mail using sendmail.
>
> However, the way the system is configured, sendmail is not in the web
> server's $PATH.
>
> There are two fixes for this -- change the init script so that sendmail is
> in the $PATH -- or modify the web server so that the admin can set the path
> to sendmail via the control panel.
>
> At first the second option sounds good. But I wonder about the security
> implications. If someone manages to get the password for the admin control
> panel -- they could change the path to sendmail to something else -- like
> `vim` or `gcc` and then somehow craft a message that would place a backdoor
> on the system.
>
> Now, given that the input to the message is going to be a mime message
> that sounds pretty difficult. But, then again, in December tons of Joomla
> sites were open to an exploit where a malformed user-agent header allowed
> hackers to execute arbitrary code.
>
> Although in this case I care about sendmail, this is clearly an issue for
> any web application that depends on external binaries like pandoc, etc.
>
> In my use case, I am dealing with a CMS and I assume the poor user doesn't
> know anything about Haskell, init scripts, ssh, etc. So, allowing the
> location to be changed via the admin panel makes things easier because it
> can be adapted to any distribution. (Clearly, I would start by checking the
> most common locations, but provide an escape hatch for oddballs).
>
> But I don't like the idea of providing a potential attack vector.
>
> Any thoughts ?
>
> - jeremy
>
>
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/web-devel/attachments/20160209/c15c7adb/attachment.html>

From dct25-561bs at mythic-beasts.com  Tue Feb  9 18:26:37 2016
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Tue, 9 Feb 2016 18:26:37 +0000
Subject: [web-devel] path to sendmail
In-Reply-To: <CAGE_JKYFJgWtzRTeDCwbdjNN-1o-n9ReftoFGVP=uCuArKJccg@mail.gmail.com>
References: <CAGE_JKYFJgWtzRTeDCwbdjNN-1o-n9ReftoFGVP=uCuArKJccg@mail.gmail.com>
Message-ID: <CAErCyQ8Uui4LWsUi03Q+q4GmKzD1mBhxW-eHwC6BTbmNnpXV0w@mail.gmail.com>

Hi,

You could put the ability to change the setting on "the other side of the
airtight hatchway" as Raymond Chen might say: put the setting in a file and
don't provide any ability to change it remotely. Then if someone does
manage to change the setting to something nefarious, they already had write
access to your filesystem so they've not gained anything.

You can of course show the current value of the setting in the UI, along
with instructions on how to change it. Presumably your user at least has
SCP or FTP access, or else how did they install your software?

That, plus autodetection when first set up (looking in a bunch of common
places) sounds reasonably usable to me.

It might also be worth taking heart in the fact that if you're dealing with
someone running on a system that has sendmail in an unexpected place then
they're going to be having a Bad Time in all sorts of other ways, no matter
whose software they're using!

Cheers,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/web-devel/attachments/20160209/3b1d3228/attachment.html>

From jerf at jerf.org  Tue Feb  9 18:50:14 2016
From: jerf at jerf.org (Jeremy Bowers)
Date: Tue, 9 Feb 2016 13:50:14 -0500
Subject: [web-devel] path to sendmail
In-Reply-To: <CAErCyQ8Uui4LWsUi03Q+q4GmKzD1mBhxW-eHwC6BTbmNnpXV0w@mail.gmail.com>
References: <CAGE_JKYFJgWtzRTeDCwbdjNN-1o-n9ReftoFGVP=uCuArKJccg@mail.gmail.com>
 <CAErCyQ8Uui4LWsUi03Q+q4GmKzD1mBhxW-eHwC6BTbmNnpXV0w@mail.gmail.com>
Message-ID: <56BA34E6.5050007@jerf.org>

On 02/09/2016 01:26 PM, David Turner wrote:
>
> Hi,
>
> You could put the ability to change the setting on "the other side of 
> the airtight hatchway" as Raymond Chen might say:
>
It's worth providing a link to this since it's hard to find the original 
in Google:

https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=31283/

There's really not much you can do about this except perhaps simply 
require that sendmail be in the path, and even that is subject to 
concerns about whether the path is set up securely. It isn't really your 
program's problem to make sure the system it's running on is set up 
securely; it is neither capable of correctly and safely determining the 
answer to that question, nor fixing it if it could.

Disclaimer: I actually work in computer security. This isn't an 
uninformed dismissal; this is an informed dismissal. :) In particular 
the last line of the previous paragraph is a core part of my point. If 
that wasn't true I might have a different opinion, but at the point 
where we're discussing a system that can't trust that sendmail is 
actually sendmail, you've already lost.

The only thing you can do is ensure that changing the path really and 
truly requires the proper authorization and there's no way to trick that 
system.

From mark.fine at gmail.com  Sun Feb 28 22:20:52 2016
From: mark.fine at gmail.com (Mark Fine)
Date: Sun, 28 Feb 2016 14:20:52 -0800
Subject: [web-devel] HTTP Status with Streaming Request Bodies
Message-ID: <CANRZ_fnEGM-EN84bOM0a21gW1QLrTzCQWKUra7y+dZcDMekO_w@mail.gmail.com>

I'm running into a problem handling requests with streaming request bodies
that fail - using http-client, the failure takes a long time (potentially
never) to propagate. Simple code (runnable project here
<https://github.com/mfine/streamy>):

{-# LANGUAGE OverloadedStrings #-}

import Control.Monad
import Data.Conduit.Combinators
import Network.HTTP.Conduit
import System.Environment

a :: IO ()
a = do
  manager <- newManager tlsManagerSettings
  request <- parseUrl "http://httpbin.org/status/409"
  void $ httpLbs request manager

b :: IO ()
b = do
  manager <- newManager tlsManagerSettings
  request <- parseUrl "http://httpbin.org/status/409"
  void $ flip httpLbs manager request
    { requestBody = requestBodySourceChunked $ repeatM $ return "a"
    }

Running "a" above works as expected (propagating the error immediately).
Running "b" has variable results, mostly never propagating the error.
Looking at the wire, I can see that the 409 status comes back, but the
exception does not propagate.

Is there something I can do here to get quicker failure? Thanks!

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/web-devel/attachments/20160228/122c1c12/attachment.html>

From mark.fine at gmail.com  Mon Feb 29 06:49:49 2016
From: mark.fine at gmail.com (Mark Fine)
Date: Sun, 28 Feb 2016 22:49:49 -0800
Subject: [web-devel] HTTP Status with Streaming Request Bodies
In-Reply-To: <CANRZ_fnEGM-EN84bOM0a21gW1QLrTzCQWKUra7y+dZcDMekO_w@mail.gmail.com>
References: <CANRZ_fnEGM-EN84bOM0a21gW1QLrTzCQWKUra7y+dZcDMekO_w@mail.gmail.com>
Message-ID: <CANRZ_fmnf8jxgChbmJ=tHrd--Y6LwqonTOtMzbVKVm5Jnm9asQ@mail.gmail.com>

Looking through the code and experimenting, using the 'Expect:
100-continue' header resulted in the desired behavior - having the response
headers checked before the request body was streamed.

Mark

On Sun, Feb 28, 2016 at 2:20 PM, Mark Fine <mark.fine at gmail.com> wrote:

> I'm running into a problem handling requests with streaming request bodies
> that fail - using http-client, the failure takes a long time (potentially
> never) to propagate. Simple code (runnable project here
> <https://github.com/mfine/streamy>):
>
> {-# LANGUAGE OverloadedStrings #-}
>
> import Control.Monad
> import Data.Conduit.Combinators
> import Network.HTTP.Conduit
> import System.Environment
>
> a :: IO ()
> a = do
>   manager <- newManager tlsManagerSettings
>   request <- parseUrl "http://httpbin.org/status/409"
>   void $ httpLbs request manager
>
> b :: IO ()
> b = do
>   manager <- newManager tlsManagerSettings
>   request <- parseUrl "http://httpbin.org/status/409"
>   void $ flip httpLbs manager request
>     { requestBody = requestBodySourceChunked $ repeatM $ return "a"
>     }
>
> Running "a" above works as expected (propagating the error immediately).
> Running "b" has variable results, mostly never propagating the error.
> Looking at the wire, I can see that the 409 status comes back, but the
> exception does not propagate.
>
> Is there something I can do here to get quicker failure? Thanks!
>
> Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/web-devel/attachments/20160228/d2d8520a/attachment.html>

From lemming at henning-thielemann.de  Tue Mar  1 19:54:33 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 1 Mar 2016 20:54:33 +0100 (CET)
Subject: [web-devel] Keep too busy crawlers away from your server
Message-ID: <alpine.DEB.2.02.1603012044070.9041@sputnik>


I know there are more sophisticated tools for that task, but I wrote a 
pretty simple program that works for me reliably for several months now. 
See the attached program. It scans the last 100 KB of a log-file you 
specify as command-line argument and checks whether certain clients excess 
allowedAccessesPerSecond. If so, their IPs are written to a blocked-hosts 
file and are removed from there only 5 days later. The blocked-hosts file 
in my example is used by arno-iptables-firewall to actually block the IP 
addresses. I added this program to my crontab:

# m h  dom mon dow   command
* * * * *      process-log /var/log/http-access.log >>/var/log/http-block.log 2>>/var/log/http-block.err
-------------- next part --------------
A non-text attachment was scrubbed...
Name: process-log.hs
Type: text/x-haskell
Size: 5276 bytes
Desc: 
URL: <http://mail.haskell.org/pipermail/web-devel/attachments/20160301/7db372bb/attachment.hs>

From jkarni at gmail.com  Sat Mar 19 15:59:18 2016
From: jkarni at gmail.com (Julian Arni)
Date: Sat, 19 Mar 2016 16:59:18 +0100
Subject: [web-devel] [ANN] servant 0.5
Message-ID: <CAPSChMPL+_ycRP=QMOk6C7pJTsqypqP+mmMK=vHwWb+3uzAwgA@mail.gmail.com>

Dear all,

We have just released a new major version (0.5) of the official servant
packages:

  - servant
  - servant-server
  - servant-client
  - servant-docs
  - servant-foreign
  - servant-js
  - servant-cassava
  - servant-blaze
  - servant-lucid
  - servant-mock

(servant-js and servant-foreign are being released for the first time.
 servant-jquery will be deprecated in favour of servant-js)

This new version brings quite a number of significant changes. Servant is
now
faster, more correct, more replete with features, and more consistent. We
have a
blog post going into more details about the changes:


http://haskell-servant.github.io/posts/2016-03-19-servant-0.5-release.html

Note also that we have revamped our tutorial, and moved it to readthedocs:

    http://haskell-servant.readthedocs.org/en/master/

Enjoy the weekend,
  Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/web-devel/attachments/20160319/3aa18d55/attachment.html>

From andrew.thaddeus at gmail.com  Wed Nov 23 15:28:56 2016
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Wed, 23 Nov 2016 10:28:56 -0500
Subject: [web-devel] ToWidget instances for Text and friends
Message-ID: <20161123152856.GA30386@thadasaurus>

I have copied the body of this github issue get feedback on this
suggestion:

https://github.com/yesodweb/yesod/issues/1298

The ToWidget typeclass could be more helpful than it currently
is. Notably, there are sensible instances for Text, lazy Text, and text
Builder that are not provided. I think that one objection to introducing
such classes is that there is a piece of syntax in the shakespeare
quasiquoter ^{..} that calls ToWidget on its argument. Adding more
instances would allow the end user to feed text into this construct,
which might be undesirable.

I don't use the quasiquoter for templating, so the downside of it
doesn't bother me. The reason I would like these instances is because
there are a number of situations where I have to call `toWidget .  toHtml`
in my code that could be abbreviated to toWidget if these instances were
provided. If this change is at odds with the goals of the TH templating,
then I wouldn't want to mess that up for people, but if not, I would
find these instances useful.

I would appreciate any feedback, even if it's just in the form of a +1
or -1 response without any further explanation.

-Andrew Martin

From michael at snoyman.com  Thu Nov 24 06:32:53 2016
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 24 Nov 2016 08:32:53 +0200
Subject: [web-devel] Feedback request: new Yesod development server
Message-ID: <CAKA2Jg+4AsEqy9iOE+E+CWLHNLM=nF2X0hgBhGa4XYAcKexX2w@mail.gmail.com>

Hey all,

I've just published a blog post describing an (almost total) rewrite of the
`yesod devel` server:

http://www.yesodweb.com/blog/2016/11/new-yesod-devel-server

This new version is not yet released, I'm requesting feedback before doing
so. If people can have a look, I'd appreciate it.

I'm including the web-devel list, since this new version has very explicit
documentation on how to use `yesod devel` with non-Yesod application.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/web-devel/attachments/20161124/9dc10210/attachment.html>

From jos at vandenoever.info  Thu Nov 24 14:06:31 2016
From: jos at vandenoever.info (Jos van den Oever)
Date: Thu, 24 Nov 2016 14:06:31 +0000
Subject: [web-devel] Feedback request: new Yesod development server
In-Reply-To: <CAKA2Jg+4AsEqy9iOE+E+CWLHNLM=nF2X0hgBhGa4XYAcKexX2w@mail.gmail.com>
References: <CAKA2Jg+4AsEqy9iOE+E+CWLHNLM=nF2X0hgBhGa4XYAcKexX2w@mail.gmail.com>
Message-ID: <4334195.JWJQjyJt9o@joga>

On Thursday 24 November 2016 08:32:53 you wrote:
> I've just published a blog post describing an (almost total) rewrite of the
> `yesod devel` server:
> 
> http://www.yesodweb.com/blog/2016/11/new-yesod-devel-server
> 
> This new version is not yet released, I'm requesting feedback before doing
> so. If people can have a look, I'd appreciate it.
> 
> I'm including the web-devel list, since this new version has very explicit
> documentation on how to use `yesod devel` with non-Yesod application.

Excited to see this. yesod devel is convenient and I use it constantly. It's a 
bit of a CPU hog though. My projects large and the relinking on every save 
sips a lot of juice.

Will yesod devel continue to work with cabal files? I've a fairly large set of 
dependencies and have not managed to get these fulfilled by stack release.

Cheers,
Jos


From michael at snoyman.com  Thu Nov 24 13:29:13 2016
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 24 Nov 2016 15:29:13 +0200
Subject: [web-devel] Feedback request: new Yesod development server
In-Reply-To: <4334195.JWJQjyJt9o@joga>
References: <CAKA2Jg+4AsEqy9iOE+E+CWLHNLM=nF2X0hgBhGa4XYAcKexX2w@mail.gmail.com>
 <4334195.JWJQjyJt9o@joga>
Message-ID: <CAKA2JgK3eZQJ2_n8UMKb4GdWTqa8U=Yvjp6txATQgpy=OV7qhQ@mail.gmail.com>

On Thu, Nov 24, 2016 at 4:06 PM, Jos van den Oever <jos at vandenoever.info>
wrote:

> On Thursday 24 November 2016 08:32:53 you wrote:
> > I've just published a blog post describing an (almost total) rewrite of
> the
> > `yesod devel` server:
> >
> > http://www.yesodweb.com/blog/2016/11/new-yesod-devel-server
> >
> > This new version is not yet released, I'm requesting feedback before
> doing
> > so. If people can have a look, I'd appreciate it.
> >
> > I'm including the web-devel list, since this new version has very
> explicit
> > documentation on how to use `yesod devel` with non-Yesod application.
>
> Excited to see this. yesod devel is convenient and I use it constantly.
> It's a
> bit of a CPU hog though. My projects large and the relinking on every save
> sips a lot of juice.
>
> Will yesod devel continue to work with cabal files? I've a fairly large
> set of
> dependencies and have not managed to get these fulfilled by stack release.
>
>
This will only work on a project that has a stack.yaml file. Though to
clarify: even in Stack project, we still use .cabal files.

You should be able to get the same solver behavior as with cabal if you do
something along the lines of:

    stack init --resolver ghc-7.10.3 --solver

Obviously replacing 7.10.3 with whichever version of GHC you want to use.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/web-devel/attachments/20161124/9ed17a5f/attachment.html>

From michael at snoyman.com  Sun Nov 27 12:20:23 2016
From: michael at snoyman.com (Michael Snoyman)
Date: Sun, 27 Nov 2016 14:20:23 +0200
Subject: [web-devel] ToWidget instances for Text and friends
In-Reply-To: <20161123152856.GA30386@thadasaurus>
References: <20161123152856.GA30386@thadasaurus>
Message-ID: <CAKA2JgLeCX+7Bpsr7hys87ZRhLpQ=62qMvDr0XM2oZ47HzJ8LA@mail.gmail.com>

CCing the Yesod mailing list, which may have more opinions.

I'm fine with the change if there are no objections. Want to send a PR?

On Wed, Nov 23, 2016 at 5:28 PM, Andrew Martin <andrew.thaddeus at gmail.com>
wrote:

> I have copied the body of this github issue get feedback on this
> suggestion:
>
> https://github.com/yesodweb/yesod/issues/1298
>
> The ToWidget typeclass could be more helpful than it currently
> is. Notably, there are sensible instances for Text, lazy Text, and text
> Builder that are not provided. I think that one objection to introducing
> such classes is that there is a piece of syntax in the shakespeare
> quasiquoter ^{..} that calls ToWidget on its argument. Adding more
> instances would allow the end user to feed text into this construct,
> which might be undesirable.
>
> I don't use the quasiquoter for templating, so the downside of it
> doesn't bother me. The reason I would like these instances is because
> there are a number of situations where I have to call `toWidget .  toHtml`
> in my code that could be abbreviated to toWidget if these instances were
> provided. If this change is at odds with the goals of the TH templating,
> then I wouldn't want to mess that up for people, but if not, I would
> find these instances useful.
>
> I would appreciate any feedback, even if it's just in the form of a +1
> or -1 response without any further explanation.
>
> -Andrew Martin
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/web-devel/attachments/20161127/dc9075fd/attachment.html>