- web-devel - Haskell.org

[yesod][newbie] Yesod applications on foreign architectures
by Jack Henahan 30 Jun '11

30 Jun '11

I'd like to put a small Yesod application on my university webspace, but they're on AIX 4.1, while I'm on OS X.6. Can I build for their architecture (it's gotta be PPC or i386, I think) from where I am, or am I going to need to look for some other way around the issue? ==== "Computer Science is no more about computers than astronomy is about telescopes." -- Edsger Dijkstra ====

2 1

Re: [web-devel] HttpOnly
by Chris Smith 30 Jun '11

30 Jun '11

The current situation, technically speaking, is that Snap has no official sessions package; but that will be changing in 0.6. The sessions package that will be part of 0.6 does, I believe, use your clientsession package, unless that's changed since I last looked. (I happen to be maintaining my own alternative package for typed sessions, which has two backends -- one using server-side state, and the other using your clientsession package. But that's not an official part of Snap.) Your cookie package is not likely to be useful for Snap, since parsing and rendering of cookie-related headers is already included in snap-core (and, I think, belongs there; it's a rather central part of HTTP; if we parse any headers at all, we ought to include cookies). As for http-only, I definitely think it's a good idea, in pretty much all cases where cookies are used to pass through server-side state. The kinds of cookies generated by clientsession are not really vulnerable to cookie-stealing attacks anywa due to the encryption that goes on, so it's really just an extra layer of security. But the same encryption guarantees that there's no possible use for trying to access and read those particular cookies in JavaScript, so adding the http-only flag doesn't actually prevent anything useful, and there's no reason *not* to do it. On Jun 30, 2011 7:59 AM, "Michael Snoyman" <michael(a)snoyman.com> wrote:

2 2

HttpOnly
by Michael Snoyman 30 Jun '11

30 Jun '11

Hi all, Here's one of those times I'd like to get some cross-framework discussion going. In Yesod, we use a combination of the cookie package[1] and clientsession[2] for storing user sessions. A few questions: * I recently heard that Snap also uses client-side sessions. If this is true, what packages does it use? * Can anyone think of a downside to setting HttpOnly on session cookies? * Now that I realize the option for HttpOnly is missing from the cookie package, can anyone see anything else missing from its API? In general, given that cookies are one of those ill-specified, very finicky parts of the web, I'd like it if we could try to converge on a single package for cookie parsing/rendering (both server and client side). Currently, Yesod and wai-test[3] both use it. Assuming we ever get a "Browser"-style module for http-enumerator, I would assume we'd use it there too. Michael [1] http://hackage.haskell.org/package/cookie [2] http://hackage.haskell.org/package/clientsession [3] http://hackage.haskell.org/package/wai-test

2 1

[ Newbie ] Problem with Route type
by Kamil Ciemniewski 30 Jun '11

30 Jun '11

Hi all, I've got another newbie problem. Compiler yells at me: Handler/Admin.hs:15:3: Couldn't match type `Route master0' with `MyAppRoute' In the expression: adminLayout In the expression: adminLayout $ do { h2id <- lift newIdent; addWidget ($(widgetFile "admin/overview/index")) } In the expression: do { adminLayout $ do { h2id <- lift newIdent; addWidget ($(widgetFile "admin/overview/index")) } } The adminLayout is defined as: adminLayout widget = do mmsg <- getMessage pc <- widgetToPageContent $ do widget hamletToRepHtml $(Settings.hamletFile "admin/admin-layout") And data types are defined as: data MyApp = MyApp { getStatic :: Static -- ^ Settings for static file serving. } type Handler = GHandler MyApp MyApp type Widget = GWidget MyApp MyApp mkYesodData "MyApp" $(parseRoutesFile "config/routes") routes are: /static StaticR Static getStatic /favicon.ico FaviconR GET /robots.txt RobotsR GET / RootR GET /admin AdminR GET It's probably a silly mistake somewhere but, well.. I'm a newbie. Best regards Kamil Ciemniewski

3 2

Re: [web-devel] On moving Yesod-specific discussion to a separate list
by Chris Smith 29 Jun '11

29 Jun '11

On Jun 28, 2011 9:16 AM, "Greg Weber" <greg(a)gregweber.info> wrote: > I would much rather revisit this issue in a month or so than keep this > thread alive, but I feel the need to defend the good name of Yesod. > Yesod libraries are no more complex than other Haskell libraries. I'm not sure where we have different definitions in mind; surely it can't be controversial that web application containers are far more complex than most other libraries. Just look at the dependencies on any such project. I'd call it a fair statement that no one thought the problems of Cabal scaling to very large numbers of packages was much of a problem until web frameworks started being a big deal. It also seems rather non-controversial to point out that Yesod includes a lot more here than other options; the Snap project, for example, happily proclaims itself to work at a level of abstraction analogous to servlets, and currently makes no attempt at solving persistence, form handling, and such. In any case, sorry if that sounded like sullying the "good name" of Yesod. I didn't even think it was particularly controversial. > The issue is simply that a Yesod thread assumes you have developed a web > application in Yesod. Or if it is about implementation, it may assume you have > looked at a library's internals. As you said, it isn't about your lack of *general* web > development knowledge. It is a lack of Yesod *specific* knowledge. Yes, that's precisely my point. I can think of very few other domains of Haskell programming where having not used a specific library even if you're familiar with the kind of problem it solves causes discussion about that library to look about as meaningful as ancient heiroglyphics. OpenGL would be one, as well as GHC internals. I'm having trouble finding other examples. Again, this isn't a dig at Yesod... I don't think *anyone* has found a good way to build a web application framework that's both simple and obvious to understand and solves the hard problems. I think it's at least partly endemic to the problem domain. -- Chris Smith

3 3

wai-handler-devel problem
by Hartmut 28 Jun '11

28 Jun '11

All, I made a copy of hell-forms.hs from yesod-form package, just for doing some experiments. When I run it via the main function, the server is doing well e.g. on port 2500. HalloWelt.hs is here <http://hpaste.org/48381>. But when I try to run that program in bash console via wai-handler-devel - being in the directory where the HalloWelt.hs resides... wai-handler-devel 2600 HalloWelt withHalloWelt I get... Attempting to interpret your app... Compile failed: NotAllowed "module is not loaded: `HalloWelt' (./HalloWelt.hs)" What could be the reason for that? Thank you for any hint - Best regards Hartmut

1 1

Happstack external js
by Mister Asafe Ribeiro 28 Jun '11

28 Jun '11

How do i include a external js file, such as jquery, using blaze html in Happstack?

3 2

yesod dependency hell
by Michael Litchard 27 Jun '11

27 Jun '11

I need to use yesod-form 0.2.0. The problem is that the yesod package, and the yesod-auth package expect yesod-form to be 0.1.0* I tried changing the .cabal files but that breaks in ways that makes me think the fix is not so simple. How do I go about being able to use yesod-form 0.2.0

5 8

How do we really know if a path is safe when serving files?
by Jeremy Shaw 27 Jun '11

27 Jun '11

Hello, Most frameworks provide some sort of mechanism for serving files from a directory. Generally some subset of the url is mapped directly to files on the disk. But, with this comes the risk that users will be able to access files they should not be able to. For example, something like: http://localhost:8000/../../../etc/passwd The tricky question is, how do we determine what paths are safe and what paths are not. I think the first step is to break the url into path segments and url decode each segment. So something a bit like this: pathElements :: String -> [String] pathElements = map urlDecode . splitOnChar '/' note that we want to split on '/' before we decode. That is because the url might contain an embedded %2f, which is the '/' character. It is encoded as %2f precisely because it is *not* supposed to treated as a path separator. Now that we have a list of path segments we want to check that those path segments can actually be mapped to a valid and safe path on the disk. So, we need to filter out any path segments that contain embedded path separators (like / or \ depending on the platform). Those characters can appear in a valid url. But they can never appear in a valid path segment (they can only be used as path separators). We also want to reject any path that contains embedded "..". Or do we? In theory, we could canonicalize path, "foo/../bar" to just "bar"? Certainly *after* canonicalization, we want to reject any path that contains a ".." segment. Under windows we have some extra concerns. For example, there are special names like LPT1, COM1, etc. Also, we do not want to allow someone to specify a drive name like C:\foo. But, how do we know if we have gotten everything right ? An alternative method would be to use System.Directory.canonicalizePath on the root directory we are serving from and the requested file. Then we check that the canonicalized root directory is the prefix of the canonicalized requested path: isChild :: FilePath -> FilePath -> IO Bool isChild root requested = do root' <- canonicalizePath root requested' <- canonicalizePath requested return (root' `isPrefixOf` requested') (Needs to handle exceptions when the root or requested path does not actually exist). One issue with that solution is that it disallows the use of symlinks which point to directories outside of the root. That can be viewed as either a feature or a bug. It is also not clear that it is actually free of any security issues. So, this is what I have so far. First I use a function like the above 'pathElements' to split the url into path segments. Then I use this function to test that it is a safe/valid path: isSafePath :: [FilePath] -> Bool isSafePath [] = True isSafePath (s:ss) = isValid s && (all (not . isPathSeparator) s) && not (hasDrive s) && not (isParent s) && isSafePath ss -- note: could be different on other OSs isParent :: FilePath -> Bool isParent ".." = True isParent _ = False Something like this: let pathEls = pathElements requestPath in if (isSafePath pathEls) then let fp = joinPath (rootPath : pathEls) in .... else fail "unsafe path" Does anyone see any issues with this? Security bugs or otherwise? Thanks! - jeremy

2 1

Yesod, picture uploading, storing, rendering
by Anton Cheshkov 27 Jun '11

27 Jun '11

Hi Michael, please tell about the best way you see to upload store and render pictures in the Yesod application. How is better to store the pictures either file system or DB. It would be great to see the code example shows how to upload store and render just uploaded pictures with Yesod. I think you have something like this already. Thanks. -- Best regards, Cheshkov Anton

2 3