[Seaside] Seaside done?

[Johan Brichau]

Hi Jerry, all,

>> Seaside security is fairly poor. It doesn’t offer any protection against CSRF attacks or session hijacking.
> 
> It currently does not, but could be added pretty easily, about session
> hijacking it depends on how you implement the session tracking.

Session protection strategies can be implemented easily in Seaside using filters.
In the next release (3.4.0), we added an example WASessionCookieProtectionFilter, which implements a session tracking strategy that prevents CSRF attacks.
This implementation uses the Seaside framework to implement an effective session hijacking protection, and can be used in any Seaside version as far back as 3.0

There were other session protection filters already included in Seaside before, but they had practical downsides.
I will agree it would have been better that it was included sooner, but then again, Seaside does not include an authentication framework either.

When you say that Seaside security overall is very poor, can you compare this with other frameworks that focus on rendering web applications? Because ’security’ is way broader than what the framework allows you to do and Seaside does not even do a bad job at that point. For example, the rendering mechanism prevents explicitly from script injection attacks because all output is escaped by default, the default session keys are way better than Zoom’s meeting ids (lol ;). But if you see security-related bad practices that the Seaside framework itself promotes, please share them so we can improve.

>> The built-in basic authentication only supports MD5-hashed password which has not been considered secure since 2004. Using other authentication mechanisms is non-trivial and can lead to deploying catastrophically insecure application (don’t ask me how I know).

I don’t see how this can be true. Seaside has no built-in authentication mechanism. It depends on what you (can) use in the Smalltalk you are running it on.
If you choose to store passwords in clear text, there is nothing that any website framework will do to keep you from doing that.
If you are referring to existing authentication libraries implemented for Seaside, that may be true, but it’s by no means inherent to the framework.

>> Last but not least, handling of volume has been issue.
>> I don’t have experience with a deployed Seaside app on Pharo,
>> but I know that on VW you quickly reach a point where your app performance
>> suffers even with a couple hundred users.
> 
> Here I kind of agree, even "a couple hundred" seems like a lot in my experience.
> Of course it depends on the kind of application, but for a typical
> backoffice kind of app, database bound, my threshold in Pharo was
> always around ~20 users... per VM. My solution was to have several
> worker VMs for this, and other worker VMs for REST APIs.

This discussion heavily depends on what your application is doing. 
In my experience, the performance bottleneck is mostly found outside of Seaside (i.e. in your application code or database). The biggest performance-related impact that Seaside adds is because of its continuation state, which consumes a lot of memory (and database transactions if you run Gemstone). I will not say that this definitely impacts your application, but similarly, it does add functionality that other frameworks are not offering. 

All in all, if you write your application in C instead of Smalltalk, the same discussion would apply.

Now, that being said, the continuation state-tracking has become obsolete in the current world and it would be good if we can improve Seaside’s performance by making that optional. It actually is already possible in the framework, but there are caveats. Would be great if someone wants to explore that direction, btw.

>> With GS, you need a multitude of Gems to handle even relatively modest load.
>> I think this would be probably the worst weakness - today’s web apps are built for tens of thousands of concurrent users,
>> and even with the use of a load balancer, this would be a limiting factor for anyone
>> considering the deployment of a globally reachable web app.

There is maybe a little gap between an ‘internal web app for 2 people’ and a ‘globally reachable web app’ :)

We’re running gemstone instances of Yesplan with 150 concurrent users easily and the bottleneck on the number of users is entirely related to the application and not Seaside (although the thing I said above does apply).
Since we’re running multiple instances, we currently serve 10K concurrent users easily.

Maybe using NodeJs, you could run less instances, but there’s a limit to what any single-instance setup using any framework can do.

> The Seaside is not going nowhere, it's the tide that comes and goes :-)

I like that quote ;)

Cheers
Johan