- web-devel - Haskell.org

Yesod + email auth
by Karsten Gebbert 17 Sep '14

17 Sep '14

Hi List, I'm seeing a somewhat unexpected behaviour using Yesod.Auth.Email. What I'm doing is this: I enter a password into the form, but no email, and the login handler redirects me to /auth/page/email/login which seems to use the default layout (I specified a separate layout for auth) and does not render the login form. I can't see a method that lets me override where the user is sent on unsuccessful login, and judging from reading the sources I should be sent the LoginR way. Any idea what I could be doing wrong here? Thanks all, Karsten

2 2

Finding the redirected-to URL in http-client?
by Michael Alan Dorman 13 Aug '14

13 Aug '14

I appreciate http-client's ability to automatically handle redirections for me---even chained ones. However, I cannot seem to find a way to retrieve out what the terminal URL was---the information is presumably available within the data structures http-client uses (since there are a couple of HttpExceptions that effectively expose it), but I don't see any way to get to it through the public API. MIke.

1 0

ANNOUNCE: hplayground: haskell client-side web framework
by Alberto G. Corona 26 Jul '14

26 Jul '14

hplayground [1] is a haskell framework that compiles to JavaScript with the haste [5] compiler. It handles reactive effects under a applicative-monad that controls the modifications of the user interface. It is quite easy to create dynamic, composable applications using ordinary, beatiful, idiomatic haskell without special constructions. Rather than a framework, it is an EDSL. Full reinversion of control avoid spagetty event handlers and the monad confines the events and their effects to the subtree where they appear avoiding the problems of declarative reactive frameworks. There are examples running[4] the source code is in [1] And there is a todo reference application [3] running [2] too. There is also a blog post about that[7] Additionally, the syntax is almost identical to the formlet widgets in MFlow[6]. So most of the hplaygroud code could run also in a server if javascript is disabled. But MFlow and hplayground are completely independent projects. I hope that you enjoy it as much as I enjoyed the development of it. A big thanks to Anton Ekblad for his wonderful Haste compiler. [1] https://github.com/agocorona/hplayground [2] http://mflowdemo.herokuapp.com/todo.html [3] https://github.com/agocorona/hplay-todo [4] http://mflowdemo.herokuapp.com/noscript/wiki/browserwidgets [5] http://http://haste-lang.org/ [6] http://hackage.haskell.org/package/MFlow [7] http://haskell-web.blogspot.com.es/2014/07/hplayground-translate-your-conso… -- Alberto.

1 0

Re: [web-devel] [Haskell] ANNOUNCE: haste-perch
by Alberto G. Corona 18 Jun '14

18 Jun '14

The syntax is similar to blaze-html, but haste-perch uses the HTM-DOM in the browser to create DOM elements. blaze-html creates a html bytestring in the server that the browser must load. It uses Haste.DOM http://hackage.haskell.org/package/haste-compiler-0.2.99/docs/Haste-DOM.html Haste.DOM has primitives that invoke Javascript functions in browser like: For example newElem invoke "createElement" in javascript Perch assemble a sequence of DOM calls that create the HTML tree directly in the browser. so you can create an application that run fully in the browser The tree can change depeding on different actions done by the user by changing the HTML tree dynamically. It is possible to create dynamic applications. 2014-06-18 18:11 GMT+02:00 Andrew Gibiansky <andrew.gibiansky(a)gmail.com>: > Could you elaborate on how this is better/different from blaze-html? > > I'm a bit confused - is it just the same thing but works with Haste, while > blaze-html doesn't? What's the main idea? > > Thanks! > Andrew > > > On Wed, Jun 18, 2014 at 7:02 AM, Alberto G. Corona <agocorona(a)gmail.com> > wrote: > >> Hi, >> >> haste-perch defines builder elements (perchs) for Haste.DOM elements that >> are appendable, so that dynamic HTML can be created in the client in a >> natural way, like textual HTML, but programmatically and with the advantage >> of static type checking. It can be ported to other haskell-js compilers. >> >> http://hackage.haskell.org/package/haste-perch >> >> This program, when compiled with haste: >> >> main= do >> withElem "idelem" $ build $ do >> div $ do >> div $ do >> p "hello" >> p ! atr "style" "color:red" $ "world" >> >> return () >> >> Creates these element: >> >> <div id= "idelem"> <-- was already in the HTML >> <div> >> <div> >> <p> hello </p> >> <p style= "color:red"> world </p> >> </div> >> </div> >> </div> >> >> Since the creation is in the browser, that permit quite dynamic pages for >> data >> presentation, and interctive textual (a.k.a "serious") applications and, >> in general >> the development of client-side web frameworks using haskell with the >> haste compiler. >> >> >> See the README in the git repository: >> >> https://github.com/agocorona/haste-perch >> >> -- >> Alberto. >> >> _______________________________________________ >> Haskell mailing list >> Haskell(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell >> >> > -- Alberto.

1 1

ANNOUNCE: haste-perch
by Alberto G. Corona 18 Jun '14

18 Jun '14

Hi, haste-perch defines builder elements (perchs) for Haste.DOM elements that are appendable, so that dynamic HTML can be created in the client in a natural way, like textual HTML, but programmatically and with the advantage of static type checking. It can be ported to other haskell-js compilers. http://hackage.haskell.org/package/haste-perch This program, when compiled with haste: main= do withElem "idelem" $ build $ do div $ do div $ do p "hello" p ! atr "style" "color:red" $ "world" return () Creates these element: <div id= "idelem"> <-- was already in the HTML <div> <div> <p> hello </p> <p style= "color:red"> world </p> </div> </div> </div> Since the creation is in the browser, that permit quite dynamic pages for data presentation, and interctive textual (a.k.a "serious") applications and, in general the development of client-side web frameworks using haskell with the haste compiler. See the README in the git repository: https://github.com/agocorona/haste-perch -- Alberto.

1 0

WAI 3.0
by Michael Snoyman 05 May '14

05 May '14

A few weeks ago, I wrote a blog post about a proposal for WAI 3.0, which would no longer be based on conduit, and therefore be open to various streaming data frameworks. The response I've received so far has been (I think universally) positive, and therefore I'd like to move forward. There was a good discussion on Reddit[1], but I think the mailing list is a better way to come to consensus on a last few points. In particular, there are two questions still up in the air: 1. Twan raised the question[2] of how to deal with the streaming response body. We need the ability to either emit a new Builder, or flush the stream. I believe we have three different interfaces available to choose from: a. (Maybe Builder -> IO ()) -> IO () b. (Builder -> IO ()) -> IO () -> IO () c. data ResponseStream = ResponseStream { responseStreamPart :: Builder -> IO () , responseStreamFlush :: IO () } ResponseStream -> IO () (a) is probably the simplest, but also likely to be the least efficient. I tend towards choosing (b), since it avoids the need for an extra datatype, but (c) looks cleaner overall. 2. Dan[3] and Stephen[4] both raised issues about how we'd deal with scarce resource allocation when creating a streaming response. Here's a summary: a. The approach I linked to in the blog came down to the bracket pattern. The downsides of this are (i) a poorly behaving application could call the callback multiple times, and (ii) it complicates the interface. b. To avoid problem (i), we could use something like the Acquire datatype[5], making the type signature `type Application = Request -> Acquire Response`. I'm overall negative on this, as the goal here is to continue simplifying to standard datatypes. c. Stephen's suggestion is to include a cleanup action in the ResponseStream constructor. My primary concern here is that it will be very difficult for application authors to write async-exception-safe code, vs option (a) which makes it trivial. On both of these questions, new ideas are certainly welcome. Michael [1] http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_gutti… [2] http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_gutti… [3] http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_gutti… [4] http://www.reddit.com/r/haskell/comments/246e39/disemboweling_wai_aka_gutti… [5] http://hackage.haskell.org/package/resourcet-1.1.2/docs/Data-Acquire.html

1 0

ANN: uhttpc - Minimal HTTP client library optimized for benchmarking
by Herbert Valerio Riedel 30 Apr '14

30 Apr '14

Hello web-devel, (sorry if you get this twice, I originally sent this from an unsubscribed email address) Even though I already announced this on reddit[1], I was reminded by one of the comments this special-interest-group list exists, and therefore I'd like to point your attention to http://hackage.haskell.org/package/uhttpc which (as was pointed out by one reddit commenter) can be regarded as the client-side of acme-http. I've been able to get comparable measurements to what weighttp and ab reports against HTTP servers such as nginx, but I've noticed some sub-optimal results when using only a single kept-alive connection. For instance, on my i7-3770 Linux desktop against an nginx server I get: ,---- | $ uhttpc-bench -n 200000 -t1 -c2 -k http://localhost/ | uhttpc-bench - a Haskell-based ab/weighttp-style webserver benchmarking tool | | starting benchmark... | finished in 15.024069 seconds, 200000 reqs (1 conns), 13312.0 req/s received | status codes: 200000 HTTP-200 | data received: 11153.977 KiB/s, 171600000 bytes total (49200000 bytes http + 122400000 bytes content) | rtt min/avg/max = 0.038/0.074/9.928 ms `---- vs. ,---- | $ uhttpc-bench -n 200000 -t1 -c2 -k http://localhost/ | uhttpc-bench - a Haskell-based ab/weighttp-style webserver benchmarking tool | | starting benchmark... | finished in 4.849609 seconds, 200000 reqs (2 conns), 41240.4 req/s received | status codes: 200000 HTTP-200 | data received: 34554.976 KiB/s, 171600000 bytes total (49200000 bytes http + 122400000 bytes content) | rtt min/avg/max = 0.031/0.048/7.207 ms `---- Whereas running `weighttp` with -c1 vs -c2 gives a linear 1x factor scaling of 20k req/s vs 40k req/s (as opposed to the 1.5x factor scaling of uhttpc-bench between -c1 and -c2) Therefore, uhttpc-bench is significantly worse than weighttp when using only a single connection. I can't explain that yet. [1]: http://www.reddit.com/r/haskell/comments/23yuvs/%C2%B5http_lowlevel_http_cl…

2 1

Re: [web-devel] XSS vs charset
by Michael Snoyman 03 Apr '14

03 Apr '14

On Wed, Apr 2, 2014 at 9:08 AM, Kazu Yamamoto <kazu(a)iij.ad.jp> wrote: > Hi Michael, > > Thank you for your reply. > > > I suppose theoretically you could be talking about a situation where > Mighty > > is hosting a CGI application that receives user data and produces a > static > > HTML file as a result. > > Yes. Also I'm thinking about Yesod. > > Yesod has more of a focus on dynamic content, and in those cases, we *do* already set charset=utf8[1]. Where this would affect Yesod is in yesod-static, in which case the same logic I've applied to Mighty would apply: users should not be able to affect the content of static files under normal circumstances, so the security concern is pretty remote. [1] https://github.com/yesodweb/yesod/blob/master/yesod-core/Yesod/Core/Content… > > But it > > could be worked around by the CGI application using <meta charset=...> > > instead. > > Yes. Is this rarely used in Yesod? > > Yes. Dynamic responses don't normally go via static file serving at all. In WAI terms, we always end up with a ResponseBuilder, not a ResponseFile, for dynamic content. > > So that comes to the question: is it safe for Mighty, mime-types, etc, to > > require that all HTML files are stored as UTF-8? I'd say, as long as > > there's a way for a user to override that if necessary, it sounds good to > > me. mime-types does provide such a capability, so I'd be in favor of > > tweaking its textual types to include explicit charset information. > > Probably I was too sensitive. Based on your discussion, it is > safer/better for Mighty not to hard-code charset. > > To be clear, besides the security concerns, there is *definitely* a usability advantage in specifying charsets explicitly, in that the browser doesn't need to use defaults or guessing[2]. This just comes down to a numbers game: is it more likely that a browser will mis-guess the character encoding of UTF8 data, or that someone running Mighty will provide non-UTF8 data? One other point in the favor of specifying encoding type is that serving of a file will *reliably* fail. Without a charset, some browsers may guess the wrong character encoding while others won't, which makes it difficult to debug. If you *always* serve with charset=utf8 and that turns out to be wrong, you'll find out quickly and reliably. [2] http://en.wikipedia.org/wiki/Charset_detection

2 3

Re: [web-devel] XSS vs charset
by Michael Snoyman 02 Apr '14

02 Apr '14

Forgot to CC the list. On Wed, Apr 2, 2014 at 8:51 AM, Michael Snoyman <michael(a)snoyman.com> wrote: > I'm not sure if Mighty is really vulnerable to this attack. IIUC, you're > worried about a static file receiving some compromised data from a user > which includes a UTF-7 sequence. However, Mighty is only serving static > data files (as opposed to generating HTML from a database query or > something), so if a user is able to compromise those already, it sounds > like *nothing* you can do would prevent an attack. > > I suppose theoretically you could be talking about a situation where > Mighty is hosting a CGI application that receives user data and produces a > static HTML file as a result. In that case, you would be open to an attack. > But it could be worked around by the CGI application using <meta > charset=...> instead. > > Putting aside the question of this specific attack for the moment, what > would be the advantages and disadvantages of forcing charset=utf-8? > > * Advantage: if the data is actually UTF-8, the browser will always treat > it as such. Without such a specification, a browser is free to guess at > some other character encoding. > * Disadvantage: if the data isn't actually UTF-8, then the browser will > have no ability to try to guess the correct encoding instead. > > So that comes to the question: is it safe for Mighty, mime-types, etc, to > require that all HTML files are stored as UTF-8? I'd say, as long as > there's a way for a user to override that if necessary, it sounds good to > me. mime-types does provide such a capability, so I'd be in favor of > tweaking its textual types to include explicit charset information. > > > On Wed, Apr 2, 2014 at 8:02 AM, Kazu Yamamoto <kazu(a)iij.ad.jp> wrote: > >> Hi all, >> >> I heard that if an HTTP server does not specify charset for text/html >> in HTTP responses, XSS would be possible: >> >> http://openmya.hacker.jp/hasegawa/security/utf7cs.html >> >> I would like to change Mighty to specify charset=UTF-8. Before that, I >> would like to discuss some items on this ML. >> >> - Can we assume that recent contents are written in UTF-8? >> For Japanese community, the answer is probably YES. >> - Which components should spcify charset=UTF-8? >> The mime-types package? >> >> --Kazu >> _______________________________________________ >> web-devel mailing list >> web-devel(a)haskell.org >> http://www.haskell.org/mailman/listinfo/web-devel >> > >

1 0

XSS vs charset
by Kazu Yamamoto 02 Apr '14

02 Apr '14

Hi all, I heard that if an HTTP server does not specify charset for text/html in HTTP responses, XSS would be possible: http://openmya.hacker.jp/hasegawa/security/utf7cs.html I would like to change Mighty to specify charset=UTF-8. Before that, I would like to discuss some items on this ML. - Can we assume that recent contents are written in UTF-8? For Japanese community, the answer is probably YES. - Which components should spcify charset=UTF-8? The mime-types package? --Kazu

1 0