From pierce at samadhiweb.com  Tue Jan 14 15:47:45 2020
From: pierce at samadhiweb.com (Pierce Ng)
Date: Tue, 14 Jan 2020 23:47:45 +0800
Subject: [Seaside] More secure cookie auto-login for TF-Login
Message-ID: <20200114154745.GA6866@localhost.localdomain>

Hi all,

I've implemented a more secure cookie-based auto-login in TF-Login to
replace the existing simple and insecure cookie scheme.

  https://github.com/PierceNg/TF-Login/tree/password

To load, start with fresh Pharo 7 image:

    "First load Seaside."
    Metacello new 
        baseline: 'Seaside3'; 
        repository: 'github://SeasideSt/Seaside:v3.3.3/repository'; 
        load. 
        
    "Then load TF-Login."
    Metacello new 
        baseline: 'TFLogin'; 
        repository: 'github://PierceNg/TF-Login:password/src'; 
        load.

Start Test Runner to run TF-Login's tests. All 78 tests should pass. The
unit tests #testLoginLogout and #testLoginThenAutomaticLogin exercise
the cookie-based auto-login functionality.

Auto-login is also implemented in the TLTestApp demo Seaside application. See attached 
screenshot of the cookie stored in Chromium upon logging into TLTestApp.

The original cookie-based auto-login stores username and the SHA1-hashed password in client
cookies. This replacement implementation is based on Paragon Initiative's blog post on
"remember me" cookies.

  https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence

Pierce
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tflogin-cookie.png
Type: image/png
Size: 33286 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20200114/d0e23695/attachment-0001.png>

From emaringolo at gmail.com  Thu Jan 23 16:14:36 2020
From: emaringolo at gmail.com (Esteban Maringolo)
Date: Thu, 23 Jan 2020 13:14:36 -0300
Subject: [Seaside] [vwnc] Web and Persistence Framework Recommendations?
In-Reply-To: <309C1C24-26E6-4269-B42D-7C1BA5466E1A@image-ware.com>
References: <03c401d5d08d$801391f0$803ab5d0$@xtra.co.nz>
 <CH2PR13MB33202E843C99E2374E12C9F4AB0D0@CH2PR13MB3320.namprd13.prod.outlook.com>
 <045401d5d109$942f8230$bc8e8690$@xtra.co.nz>
 <CH2PR13MB332003707221AE379FF62003AB0C0@CH2PR13MB3320.namprd13.prod.outlook.com>
 <309C1C24-26E6-4269-B42D-7C1BA5466E1A@image-ware.com>
Message-ID: <CAJMgPCKyLWLK3X5k3__jCrkR1f48BmDqxMKXt5cswOjToAkk=Q@mail.gmail.com>

Hi Stewart,

I use Jerry's comment to "extend" his reply by adding my opinion about
some of the topics mentioned.

On Wed, Jan 22, 2020 at 11:04 PM Jerry Kott <jkott at image-ware.com> wrote:

> I love Seaside for its HTML semantics and ease of HTML generation. Almost everything else about it is dated and a PITA. The JS frameworks and libraries are too many and are moving too fast for the Smalltalk/Pharo/Seaside community to keep up with. As a result, even the most popular ones are way outdated.
> Take jQuery as an example: the jQuery library included with Seaside 3.2 in VW 8.3.1 is version 1.11.3 (from 2015). Even the most recent Seaside 3.3 loaded in Pharo 8.0 by default, has jQuery 3.3.1 which is approximately two years old. The current version is 3.4.1. It’s similar with every single JS library I know of, if it even has a Seaside wrapper. Many of the JS libraries release new versions to address security vulnerabilities. Thus, no matter which JS library/framework Seaside uses, it’s either outdated or insecure. We just don’t have enough developers in the community to keep up. This makes the development of secure web applications with Seaside difficult if not impossible.

I've been working with Seaside for the last 6 years, and worked with
it before too (since v 1.0), and IMO Seaside is is still the best
option in Smalltalk for complex interfaces given you do Server-Side
Rendering.

For the last 3 years I've been also using VW version of Seaside, which
is outdated, so I upgraded jQuery, Bootstrap 3, FontAwesome and a
whole set of libraries that work perfectly today. Plus a lot of other
libraries that we either use as a WAFileLibrary or link to the static
files using a file responder. One thing is to ship with a version with
a minor version change (as the 3.4.x vs 3.3.x) versus being one or two
major releases behind (as the case of the version shipped with VW).
Which in any case, except for Smalltalk wrappers for some of the
abstractions, could be solved by referencing a static url instead of
using the FileLibraries provided by Seaside.

But today you can build large scale applications developed with
Seaside, most of the scaling goes to middleware, cointainers and/or
reverse proxies architectures, instead of a single VM serving all the
requests serially (which only work in very small scales).

Seaside in VW seems outdated (albeit still useful) and no longer
maintained by Cincom (by whatever reason), and that would be the only
reason to advice against it if you don't know how to keep it up to
date.

Which is a pity, since I find VisualWorks's very robust to work with
Seaside, with the best management of breakpoints within clousures,
continuations and stack management compared with other dialects.

> When AppeX was first designed, our goal was to avoid the pitfalls of web framework integration cost that Seaside has. This was expressed by the motto “Play well with others”.
> In contrast, AppeX allows loading of any JS framework without the need for Smalltalk / AppeX wrappers, and as you pointed out, its integrated JS code management capabilities allow developers to keep the JS code for their applications as soon as a new version of a library is out. I think this is the single most important advantage of AppeX over Seaside.

This I don't understand, you can use any library you want from
Seaside, but it only has costs if you want to build Smalltalk classes
around them, jQuery being the canonical example.

But in my experience, we always ship static js along applications, and
our Seaside app uses these JS or the JS uses other third party
libraries without issues.

> The other aspect is that the JS code one can (but doesn’t have to) write the JS application code using the OO paradigm Smalltalkes know and love. Most of the JS ecosystem is not object oriented, or is a bastardized version of OO. AppeX allows you to design JS classes in hierarchies, using inheritance and polymorphism just like we do in Smalltalk. Even though one must use the JS syntax (supported by the tools as you mentioned), staying within the OO mental model and the VW IDE to write a JS app for the client browser more than makes up for that shortcoming ;).

AppeX, as mentioned, takes a different, and interesting "polyglot"
approach, aimed at Single Page Application (aka SPA's), but IMO lost
its edge for today SPA/PWA's frameworks such as React, Vue.js or
Angular (just to mention to most prominent), because they have a
different development pipeline and deployment, since there is no
"backend ready" tool for a React.js front end. So you also have to
develop your own too. Try using Grunt, Webpack or a similar tool with
AppeX.

I admit that while I read the documentation about AppeX I never used
it for any "toy project" (as I did with other frameworks, Smalltalk or
not).

> However, if one needs an internal web app not exposed to the Internet without all the JS mumbo/jumbo, the productivity of Seaside is hard to beat.

Seaside is highly productive, but there is no silver bullet and it has
its pitfalls too, like the heretic use of HTTP for non-idempotent
requests, the lack of a "convention" to easily structure an
application and get nice URLs by default, and being 100%
server-session dependant. So everything comes with a tradeoff.

As I see it today, there are two "most efficient" (or less
inefficient) ways of doing Smalltak web development today:
SSR) Server Side Rendering, either by using Seaside or any other HTTP
framework with static URLs with some templating (if the workflow is
limited or fixed)

API) REST Server in Smalltalk, frontend in JS (React/Vue/Angular).

There are hybrids there (e.g. Seaside using React/Vue components), but
are very specific use cases.

As for persistance, if you go for RDBMS, VisualWorks's Glorp is still
the canonical version, and works pretty well, either the SSR model of
Seaside (one Glorp session per Seaside session) or by pooling sessions
in a REST API server.

I leave the security part aside, since there is not much public
assessment of any of these, I have my experience and good practices
about it, but since Jerry is OSCP I'd love to know his insight about
security in Smalltalk web applications in general.

Regards,

Esteban A. Maringolo


>
> Stewart
>
> From: Degen, Vladimir [mailto:VDegen at cincom.com]
> Sent: Wednesday, 22 January 2020 9:14 a.m.
> To: Stewart MacLean <stewart at xtra.co.nz>; vwnc at cs.uiuc.edu
> Subject: RE: [vwnc] Web and Persistence Framework Recommendations?
>
> Hi Stewart,
>
> AppeX is VW's ES6/HTML5 web application framework for single page web application building.
> In AppeX-Examples you'll find "mobile device friendly content" examples and persistence examples (e.g. the Genealogy example).
> There is a wizard for quickly creating a web application with persistence (Tools...Web Development...Create a Web application).
> Also, you can take a look in the WeAppDevGuide.pdf under the topic "Create an Application" in the chapter entitled "Scaffolding".
>
> Vlad Degen, Cincom
>
> p.s. Feel free to ask further AppeX/Scaffolding questions!
> From: Stewart MacLean <stewart at xtra.co.nz>
> Sent: Tuesday, January 21, 2020 2:04 PM
> To: vwnc at cs.uiuc.edu
> Subject: [vwnc] Web and Persistence Framework Recommendations?
>
> Hi All,
>
> I’m about to embark on developing a web based system to implement a publish/subscribe business model.
>
> It has been some time since I’ve updated to the latest version of VisualWorks so I am interested in any recommendations/observations on which framework to use for
>
> 1)     the web UI front end
> 2)     the data persistence back end
>
> I don’t envisage a high transaction load, but the data model will potentially be complex. I have experience with SQL/Relational Databases, but would prefer to stay in ObjectLand if feasible. Another consideration is that I may want to use a mobile App to interface to the server as well.
>
> Thoughts/suggestions much appreciated.
>
> Cheers,
>
> Stewart
>
>

From jkott at image-ware.com  Thu Jan 23 18:22:48 2020
From: jkott at image-ware.com (Jerry Kott)
Date: Thu, 23 Jan 2020 10:22:48 -0800
Subject: [Seaside] [vwnc] Web and Persistence Framework Recommendations?
In-Reply-To: <CAJMgPCKyLWLK3X5k3__jCrkR1f48BmDqxMKXt5cswOjToAkk=Q@mail.gmail.com>
References: <03c401d5d08d$801391f0$803ab5d0$@xtra.co.nz>
 <CH2PR13MB33202E843C99E2374E12C9F4AB0D0@CH2PR13MB3320.namprd13.prod.outlook.com>
 <045401d5d109$942f8230$bc8e8690$@xtra.co.nz>
 <CH2PR13MB332003707221AE379FF62003AB0C0@CH2PR13MB3320.namprd13.prod.outlook.com>
 <309C1C24-26E6-4269-B42D-7C1BA5466E1A@image-ware.com>
 <CAJMgPCKyLWLK3X5k3__jCrkR1f48BmDqxMKXt5cswOjToAkk=Q@mail.gmail.com>
Message-ID: <32F5F684-615D-4CD9-AC41-CBEEDDC20746@image-ware.com>

Very good points, Esteban.

Referencing a static URL is always an option - it would be interesting if someone writes a blog post or something - how does it affect the Smalltalk wrapper compatibility? In a minor version it should be not an issue, but going from (e.g.) jQuery 1.11.3 to 3.4.1 - I think that can be a significant effort. Keeping the versions current and synchronized in your development / test/ production environments can also be a challenge. I have seen an ‘unexplainable’ differences in behaviour between a development environment (VW) and production (GemStone) until it became apparent that the jQuery versions were out of sync. But I digress.

I think if the Smalltalk wrappers are out of sync with a statically referenced library, and you have to drop down to writing JS by hand, the AppeX experience if better than Seaside because of the seamless IDE integration. Naturally, this will depend on the complexity of the app (SPA vs. the traditional ‘each click loads a page’), your familiarity with the tool, etc. As you say: there are always trade offs to consider.

As for publicly available security assessments - it’s something that has been on my mind for quite some time. I have done some work in that direction but nothing official yet. Just being busy. Hopefully a more concrete announcement can be made some time soon.

Jerry Kott, OSCP
Principal, Imageware Corporation <https://image-ware.com/>

Security. By choice and by design.

This message has been digitally signed.
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



> On 23-01-2020, at 8:14 AM, Esteban Maringolo <emaringolo at gmail.com> wrote:
> 
> Hi Stewart,
> 
> I use Jerry's comment to "extend" his reply by adding my opinion about
> some of the topics mentioned.
> 
> On Wed, Jan 22, 2020 at 11:04 PM Jerry Kott <jkott at image-ware.com> wrote:
> 
>> I love Seaside for its HTML semantics and ease of HTML generation. Almost everything else about it is dated and a PITA. The JS frameworks and libraries are too many and are moving too fast for the Smalltalk/Pharo/Seaside community to keep up with. As a result, even the most popular ones are way outdated.
>> Take jQuery as an example: the jQuery library included with Seaside 3.2 in VW 8.3.1 is version 1.11.3 (from 2015). Even the most recent Seaside 3.3 loaded in Pharo 8.0 by default, has jQuery 3.3.1 which is approximately two years old. The current version is 3.4.1. It’s similar with every single JS library I know of, if it even has a Seaside wrapper. Many of the JS libraries release new versions to address security vulnerabilities. Thus, no matter which JS library/framework Seaside uses, it’s either outdated or insecure. We just don’t have enough developers in the community to keep up. This makes the development of secure web applications with Seaside difficult if not impossible.
> 
> I've been working with Seaside for the last 6 years, and worked with
> it before too (since v 1.0), and IMO Seaside is is still the best
> option in Smalltalk for complex interfaces given you do Server-Side
> Rendering.
> 
> For the last 3 years I've been also using VW version of Seaside, which
> is outdated, so I upgraded jQuery, Bootstrap 3, FontAwesome and a
> whole set of libraries that work perfectly today. Plus a lot of other
> libraries that we either use as a WAFileLibrary or link to the static
> files using a file responder. One thing is to ship with a version with
> a minor version change (as the 3.4.x vs 3.3.x) versus being one or two
> major releases behind (as the case of the version shipped with VW).
> Which in any case, except for Smalltalk wrappers for some of the
> abstractions, could be solved by referencing a static url instead of
> using the FileLibraries provided by Seaside.
> 
> But today you can build large scale applications developed with
> Seaside, most of the scaling goes to middleware, cointainers and/or
> reverse proxies architectures, instead of a single VM serving all the
> requests serially (which only work in very small scales).
> 
> Seaside in VW seems outdated (albeit still useful) and no longer
> maintained by Cincom (by whatever reason), and that would be the only
> reason to advice against it if you don't know how to keep it up to
> date.
> 
> Which is a pity, since I find VisualWorks's very robust to work with
> Seaside, with the best management of breakpoints within clousures,
> continuations and stack management compared with other dialects.
> 
>> When AppeX was first designed, our goal was to avoid the pitfalls of web framework integration cost that Seaside has. This was expressed by the motto “Play well with others”.
>> In contrast, AppeX allows loading of any JS framework without the need for Smalltalk / AppeX wrappers, and as you pointed out, its integrated JS code management capabilities allow developers to keep the JS code for their applications as soon as a new version of a library is out. I think this is the single most important advantage of AppeX over Seaside.
> 
> This I don't understand, you can use any library you want from
> Seaside, but it only has costs if you want to build Smalltalk classes
> around them, jQuery being the canonical example.
> 
> But in my experience, we always ship static js along applications, and
> our Seaside app uses these JS or the JS uses other third party
> libraries without issues.
> 
>> The other aspect is that the JS code one can (but doesn’t have to) write the JS application code using the OO paradigm Smalltalkes know and love. Most of the JS ecosystem is not object oriented, or is a bastardized version of OO. AppeX allows you to design JS classes in hierarchies, using inheritance and polymorphism just like we do in Smalltalk. Even though one must use the JS syntax (supported by the tools as you mentioned), staying within the OO mental model and the VW IDE to write a JS app for the client browser more than makes up for that shortcoming ;).
> 
> AppeX, as mentioned, takes a different, and interesting "polyglot"
> approach, aimed at Single Page Application (aka SPA's), but IMO lost
> its edge for today SPA/PWA's frameworks such as React, Vue.js or
> Angular (just to mention to most prominent), because they have a
> different development pipeline and deployment, since there is no
> "backend ready" tool for a React.js front end. So you also have to
> develop your own too. Try using Grunt, Webpack or a similar tool with
> AppeX.
> 
> I admit that while I read the documentation about AppeX I never used
> it for any "toy project" (as I did with other frameworks, Smalltalk or
> not).
> 
>> However, if one needs an internal web app not exposed to the Internet without all the JS mumbo/jumbo, the productivity of Seaside is hard to beat.
> 
> Seaside is highly productive, but there is no silver bullet and it has
> its pitfalls too, like the heretic use of HTTP for non-idempotent
> requests, the lack of a "convention" to easily structure an
> application and get nice URLs by default, and being 100%
> server-session dependant. So everything comes with a tradeoff.
> 
> As I see it today, there are two "most efficient" (or less
> inefficient) ways of doing Smalltak web development today:
> SSR) Server Side Rendering, either by using Seaside or any other HTTP
> framework with static URLs with some templating (if the workflow is
> limited or fixed)
> 
> API) REST Server in Smalltalk, frontend in JS (React/Vue/Angular).
> 
> There are hybrids there (e.g. Seaside using React/Vue components), but
> are very specific use cases.
> 
> As for persistance, if you go for RDBMS, VisualWorks's Glorp is still
> the canonical version, and works pretty well, either the SSR model of
> Seaside (one Glorp session per Seaside session) or by pooling sessions
> in a REST API server.
> 
> I leave the security part aside, since there is not much public
> assessment of any of these, I have my experience and good practices
> about it, but since Jerry is OSCP I'd love to know his insight about
> security in Smalltalk web applications in general.
> 
> Regards,
> 
> Esteban A. Maringolo
> 
> 
>> 
>> Stewart
>> 
>> From: Degen, Vladimir [mailto:VDegen at cincom.com]
>> Sent: Wednesday, 22 January 2020 9:14 a.m.
>> To: Stewart MacLean <stewart at xtra.co.nz>; vwnc at cs.uiuc.edu
>> Subject: RE: [vwnc] Web and Persistence Framework Recommendations?
>> 
>> Hi Stewart,
>> 
>> AppeX is VW's ES6/HTML5 web application framework for single page web application building.
>> In AppeX-Examples you'll find "mobile device friendly content" examples and persistence examples (e.g. the Genealogy example).
>> There is a wizard for quickly creating a web application with persistence (Tools...Web Development...Create a Web application).
>> Also, you can take a look in the WeAppDevGuide.pdf under the topic "Create an Application" in the chapter entitled "Scaffolding".
>> 
>> Vlad Degen, Cincom
>> 
>> p.s. Feel free to ask further AppeX/Scaffolding questions!
>> From: Stewart MacLean <stewart at xtra.co.nz>
>> Sent: Tuesday, January 21, 2020 2:04 PM
>> To: vwnc at cs.uiuc.edu
>> Subject: [vwnc] Web and Persistence Framework Recommendations?
>> 
>> Hi All,
>> 
>> I’m about to embark on developing a web based system to implement a publish/subscribe business model.
>> 
>> It has been some time since I’ve updated to the latest version of VisualWorks so I am interested in any recommendations/observations on which framework to use for
>> 
>> 1)     the web UI front end
>> 2)     the data persistence back end
>> 
>> I don’t envisage a high transaction load, but the data model will potentially be complex. I have experience with SQL/Relational Databases, but would prefer to stay in ObjectLand if feasible. Another consideration is that I may want to use a mobile App to interface to the server as well.
>> 
>> Thoughts/suggestions much appreciated.
>> 
>> Cheers,
>> 
>> Stewart
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20200123/af1152fb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20200123/af1152fb/attachment-0001.sig>

From emaringolo at gmail.com  Thu Jan 23 20:17:00 2020
From: emaringolo at gmail.com (Esteban Maringolo)
Date: Thu, 23 Jan 2020 17:17:00 -0300
Subject: [Seaside] [vwnc] Web and Persistence Framework Recommendations?
In-Reply-To: <CH2PR13MB33209F81CD0CC59695C60743AB0F0@CH2PR13MB3320.namprd13.prod.outlook.com>
References: <03c401d5d08d$801391f0$803ab5d0$@xtra.co.nz>
 <CH2PR13MB33202E843C99E2374E12C9F4AB0D0@CH2PR13MB3320.namprd13.prod.outlook.com>
 <045401d5d109$942f8230$bc8e8690$@xtra.co.nz>
 <CH2PR13MB332003707221AE379FF62003AB0C0@CH2PR13MB3320.namprd13.prod.outlook.com>
 <309C1C24-26E6-4269-B42D-7C1BA5466E1A@image-ware.com>
 <CAJMgPCKyLWLK3X5k3__jCrkR1f48BmDqxMKXt5cswOjToAkk=Q@mail.gmail.com>
 <CH2PR13MB33209F81CD0CC59695C60743AB0F0@CH2PR13MB3320.namprd13.prod.outlook.com>
Message-ID: <CAJMgPCJPYqYit+sGVwNke5e7FdjMoaLK46UrgCf6_Eump-2Jmw@mail.gmail.com>

On Thu, Jan 23, 2020 at 3:40 PM Degen, Vladimir <VDegen at cincom.com> wrote:
>
> Hi Esteban,
>
> First, you'll be happy to hear that we just recently updated VW Seaside to version 3.3.4.

Great! Any ETA of its availability?
(I have no rush to migrate the current code, just to know.)

> We are of course glad to hear that you consider VW "very robust to work with Seaside, with the best management of breakpoints within closures, continuations and stack management " :).

I find it surprisingly stable. To the point sometimes I forget the
save the image during a whole workday (moral hazard? :-) ).

> On to AppeX.
> The most simple thing to do in AppeX is naturally to use HTML5 and vanilla JavaScript to build an application.
> However AppeX, as a JavaScript IDE and web application hosting environment, attempts to remain agnostic as to whatever JavaScript libraries the developer wishes to incorporate in their application.  There are examples of using external libraries scattered throughout the examples, e.g. in the Genealogy and mobile examples.


> Here are a few of the new/improved features of AppeX:
> 1.  automatic synchronization between internal JS code and external files so that, for instance, a developer can change their code in a chrome debugger and have those changes propagate to the JS refactoring browser in Smalltalk

How would this work? If you change something in the debugger you're
working on a read-only version of the served resource (from a HTTP
server).

> 4.  AppeX's build and deployment workflow has also been undergoing improvement; e.g. one can set on automatic JS code minification, and bundling together of JS files to serve as a single file during deployment.

Doesn't loading all the JS resources into the image make the image
grow, and so the publishing/versioning of the packages containing it?
I found that accidentally selecting the "content" selectors in some of
Seaside File Libraries would block the UI for a while until the whole
content was parsed.

Another remarkable point is that SiouX supports HTTP/2, which is
useful if you serve directly from the VW VM.

Is there a way to make the request/response multithreaded at the VM level?

Regards,

--
Esteban A. Maringolo