June 2011 - web-devel

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

Install on windows
by Oscar Picasso 26 Jun '11

26 Jun '11

Hi, I tried to install yesod as explained in "Yesod In Five Minutes". I am using Haskell Platform 2011.2.0.1 on Windows Vista but I get: c:\programs\emacs-22.2\bin>cabal install yesod cabal install yesod Resolving dependencies... Downloading attempt-0.3.1... Configuring attempt-0.3.1... Preprocessing library attempt-0.3.1... Building attempt-0.3.1... Data\Attempt.hs:54:8: Could not find module `Control.Failure': There are files missing in the `failure-0.1.0.1' package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. cabal: Error: some packages failed to install: attempt-0.3.1 failed during the building phase. The exception was: ExitFailure 1 control-monad-attempt-0.3.0 depends on attempt-0.3.1 which failed to install. yesod-0.8.2.1 depends on attempt-0.3.1 which failed to install. yesod-auth-0.4.0.2 depends on attempt-0.3.1 which failed to install. Oscar Picasso

1 0

Overlapping in routes
by Alexey Khudyakov 26 Jun '11

26 Jun '11

Hello! I thought about routes and overlapping. I'm not talking about actual implementation but rather trying to construct simple model. First of all what is overlapping in routes? Simplest definition is routes do not overlap if any URL match to one route or do not match. Bad thing it couldn't be checked statically. Using for example Eric's routes. > /add > /#Int This routes do not overlap. We can make this conclusion because we know SinglePiece instance of Int. Overlapping checker could not have this information. Better definition is. Routes do not overlap is any URL could be mapped to one or zero routes assuming that SinglePiece match any piece. Now lets consider case of unlimited overlapping. Routes are matched from top to bottom. First route to match is selected. If singlePiece or multiPiece field fails then next route is matched. So it's very similar to pattern matching in haskell functions. It has a problem though. There may be inconsitencies. For example: > / HomeR > /#String StrR > /#Int IntR Then roundtrip (route → URL → route) for IntR becomes: > IntR 42 → "/42" → StrR "42" IMHO overlapping should be disabled by default. Should it be possible to enable overlapping? How should it be resolved. Method above seems to be most intuitive (at least for me). P.S. I didn't touch subsites and multipiece parts for simplicity.

2 2