Yesod 1.0 - a robust, friendly, high performance web framework for Haskell • Hacker News Board

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#61

Post by gregwebs » Mon, Apr 09, 2012, 7:27 PM UTC

shadowfiend wrote: post #57

snoyberg wrote: post #47

Earlier quoted context omitted.

The clientsession package (which is what we use) both encrypts and applies a hash to the payload. Hashing prevents users from tampering with the data, and encrypting prevents inspection of the data. This means that you can even store sensitive data in a cookie without worrying if it's being compromised. (Not to say I recommend that practice, but it is possible.) There is of course some performance overhead to encrypt…

The content of the cookie isn't compromised, but you can trivially sidejack a cookie on an unencrypted connection and access the information through the website itself, in essence stripping any security. Arguably encrypting the cookie is a waste of processor time, but more importantly I think you may be giving people a false sense of security. The proper way to do secure interactions is via SSL, and I'm not sure encr…

SSL is (important as you say but) orthogonal to this issue. If you steal a non-encrypted cookie and take over a user's session the result is the same.

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#62

Post by papsosouid » Mon, Apr 09, 2012, 7:35 PM UTC

stepcut wrote: post #60

papsosouid wrote: post #56

Earlier quoted context omitted.

Hmm, I'm sorry to have (mis)spoken for you. I assumed you would tell him that since you appear to have been pretty open about it on the mailing list and in IRC. So you think happstack-server is better than snap-server? Or just that I am over-stating the difference? I know there was talk of switching happstack over to warp, and then more recently of writing another server instead. What is it you are planning to do bet…

I think that as far as the end user is concerned, there is not much difference between the warp, Snap, and Happstack backends. Speed-wise, warp is maybe 3 times faster than Snap and Happstack in the pong test. Though, how that plays out in real world is hard to say. But, I doubt anyone is running a Haskell web server right now that needs anywhere close to 30,000+ requests/second. Of course, speed never hurts. Even if…

Getting offtopic here, but what would you say is the difference between snap and happstack? I ignored happstack for the longest time because of the association with what is now acid-state. When snap came along I checked it out, and then more recently I looked at happstack and got a "so, it's pretty much the same as snap?" feel. Is snap just a better marketed happstack? What would your sales pitch for happstack be to a snap user?

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#63

Post by zoowar » Mon, Apr 09, 2012, 7:40 PM UTC

Over the weekend I played with happstack, snap, and yesod. Yesod rubbed me the wrong way, I just didn't like the approach they took. Still, of the 3, they have the most compelling set of features making it hard to consider the other 2. For example authentication provides many options, including browserid.

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#64

Post by shadowfiend » Mon, Apr 09, 2012, 7:42 PM UTC

gregwebs wrote: post #61

shadowfiend wrote: post #57

Earlier quoted context omitted.

The content of the cookie isn't compromised, but you can trivially sidejack a cookie on an unencrypted connection and access the information through the website itself, in essence stripping any security. Arguably encrypting the cookie is a waste of processor time, but more importantly I think you may be giving people a false sense of security. The proper way to do secure interactions is via SSL, and I'm not sure encr…

SSL is (important as you say but) orthogonal to this issue. If you steal a non-encrypted cookie and take over a user's session the result is the same.

Yes, that's precisely what I'm saying. So, let me put it differently: what security advantage does an encrypted session cookie confer? I see two possibilities:

- Someone who hijacks a request with the cookie in it cannot see the data in the cookie. But they can access the site as the user, so there is no real world benefit to this fact. - Someone on the same computer cannot see the data in the cookie. But again, they have the cookie value, so they can access the site as the user, so there is again no real world benefit to the fact that they can't see the data in the cookie itself, because they can interact with the site and see the data there.

I guess I'm just looking for an example scenario where the cookie being encrypted offers a concrete benefit from a security standpoint.

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#65

Post by yogsototh » Mon, Apr 09, 2012, 7:55 PM UTC

SkyMarshal wrote: post #35

From the Learn More link at the bottom [1]: > Note the awesome Shakespearean inspired name convention. Another good reason to use yesod. Lol. > Until here I believe it goes in the right direction. Even if I believe the real future is by generating HTML pages from the client (using javascript) and server limited to serve JSON (or XML, or any object representation system). This is a little unclear. Do you mean, prior t…

Mainly, I believe that most the energy put in Yesod goes on the problem I find the most important.

- Security by default, directly imported from the Haskell type system.

- Fast, also, because Haskell is quite fast compared to most languages used for the web.

- Able to manage a lot of concurrent connexions,

- Incredible foundation language, Haskell is simply awesome (look at my latest blog post for details[^1]).

On the other hand, IMHO, the future of the web might be:

- an API server as good as possible (fast/distributed/clever)

- many good quality dynamic (and generally native) clients

Therefore, I find most of the effort put in the HTML/CSS/JS generation while impressive not so essential for what I look. On the other hand, the notion of Yesod's widget is a very clever first step in the direction of web component abstraction. So in conclusion, yes, Yesod went a step further from what I expected from server side web technologies when I discovered it.

[^1]: http://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Way...

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#66

Post by ique » Mon, Apr 09, 2012, 7:58 PM UTC

gregwebs wrote: post #10

Argorak wrote: post #6

I have one question about yesod: how easy is it to switch templating languages? I had a look at it more than once, but hamlet always turned me off. Is it easy to switch to, say, hastache?

hamlet is by far Yesod's best feature. I have already ported it to Ruby (hamlet.rb) and Javascript (hamlet.js). Many users come with different pre-conceptions about what a good template language should be, but once they actually start using Hamlet, they love it. So honestly I am not 100% sure how much effort using a different template language is because not a single user has wanted to switch to an alternative. That…

My problem with Hamlet is that using it would cause a lot of unneeded pains and errors. I have a team of consultants doing all HTML coding, and they've been doing HTML for years (and are thus accustomed to writing pure HTML). If they just happen to close a single tag anywhere in any page, the application crashes.

If that is robust, then I'm not sure what definition you are using.

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#67

Post by Periodic » Mon, Apr 09, 2012, 8:07 PM UTC

shadowfiend wrote: post #58

marshray wrote: post #51

Earlier quoted context omitted.

Encrypting and authenticating cookies allows the web app server (or server farm) to store some session state in the browser rather than hit the database for every little thing. This can have a huge positive effect on scalability.

I'm aware of the benefits of using cookies for session state, just not sure encryption itself offers serious benefits without encrypting the entire browser session via SSL. And it may offer disadvantages from an understanding standpoint, where people think the encrypted cookie provides more security than it actually does.

If properly encrypted with an authenticated encryption mechanism then the server can be sure that the data has not been modified and has not been read. This would allow private data to be stored. As long as the server is the only one that knows the key, then only the server can read it. An evesdropper can still use the cookies for replay attacks, but at that point they're on the connection already.

It's useful for things like storing the current user session. You wouldn't want someone to be able to log in and then change their account to someone else's by modifying the user id in their cookie. Thus this information is often stored in a server-side session. With an encrypted cookie you can push this data to the client, which makes the server stateless with respect to client sessions.

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#68

Post by santadays » Mon, Apr 09, 2012, 8:12 PM UTC

shadowfiend wrote: post #64

gregwebs wrote: post #61

Earlier quoted context omitted.

SSL is (important as you say but) orthogonal to this issue. If you steal a non-encrypted cookie and take over a user's session the result is the same.

Yes, that's precisely what I'm saying. So, let me put it differently: what security advantage does an encrypted session cookie confer? I see two possibilities: - Someone who hijacks a request with the cookie in it cannot see the data in the cookie. But they can access the site as the user, so there is no real world benefit to this fact. - Someone on the same computer cannot see the data in the cookie. But again, they…

I might be wrong here but I think it prevents against a user tampering their own cookie. Say I store User_Id:5 in a cookie and pass it over an ssl connection. The user can still change from User_Id:5 to User_Id:6 and get user 6's account info. Typically you would have to store a non guessable token instead to avoid this. I think by encrypting the cookie you provide the non-guessable part of the equation without having to think about it. This isn't really a benefit from a security standpoint (as in it doesn't provide more security), but it is convenient.

Could be wrong here, I'm not very familiar with Yesod.

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#69

Post by gregwebs » Mon, Apr 09, 2012, 8:27 PM UTC

papsosouid wrote: post #55

gregwebs wrote: post #39

Earlier quoted context omitted.

Its not absurd, that has been our experience the majority of the time. Your comment about Yesod having nothing unique shows you never really used Yesod or are very intentionally trolling. For example, Snap does not have type-safe urls and Happstack has a very different approach to its related routing. I could come up with a lot of other examples.

>Its not absurd, that has been our experience the majority of the time. It is absurd, and saying "I only look at people who like hamlet, and all I see is people who like hamlet" doesn't make it any less absurd. >Your comment about Yesod having nothing unique shows you never really used Yesod or are very intentionally trolling Again, stop with the accusations and consider the very real possibility that not everyone sh…

You say you can use type-safe urls, but you aren't actually doing it. And the reason why is it isn't supported end-to-end by your framework. You can't stick one in a Heist template, and your routing code would become more tedious because routing is not completely trivial.

But Again, this is just one example.

In your case I doubt any benefits you would receive from switching to Yesod would overcome your switching costs. I would love to have a reasonable discussion about it. But you chose to give us zero feedback until we make a 1.0 release announcement (which means we are going to now limit our changes) and then come out of the wood-work and pic at every nit you can find in the comments of the release announcement and state some other framework is better. Stopping by #yesod to discuss, criticizing on the mail list, or helping your own favorite framework reach 1.0 would be a lot more productive.

Edit (because I can't reply): Thanks for bringing up issues on IRC. If you ask on the mail list you are guaranteed a thoughtful answer. We push users towards Hamlet in part because of the type-safe url support, but you are definitely welcome to use any template language you want.

Re: Yesod 1.0 - a robust, friendly, high performance web framework for Haskell

#70

Post by cies » Mon, Apr 09, 2012, 8:29 PM UTC

shadowfiend wrote: post #64

gregwebs wrote: post #61

Earlier quoted context omitted.

SSL is (important as you say but) orthogonal to this issue. If you steal a non-encrypted cookie and take over a user's session the result is the same.

Yes, that's precisely what I'm saying. So, let me put it differently: what security advantage does an encrypted session cookie confer? I see two possibilities: - Someone who hijacks a request with the cookie in it cannot see the data in the cookie. But they can access the site as the user, so there is no real world benefit to this fact. - Someone on the same computer cannot see the data in the cookie. But again, they…

i can think of only one case: that in which the site owners dont want the user (or sidejacker in case of a non-SSL connection) to see some data they wish to put in the cookie.

i'd cannot think of a web app i worked on where this was needed.

(the hashing is cool though -- tinker prevention is common to be a-good-thing)