I know things have been very quiet lately, so I just wanted to drop a quick progress update on 2.07.  Progress is going well, but a little slower than expected.  Combined with a bit of a late start in August, it looks like it will be mid-October for the first beta.

As previously mentioned, 2.07 will include:

- SSL and GZip support in the EWB Web Server
- Server-side application execution in the EWB Web Server
- Server-side application creation in the EWB IDE

The server-side application support includes a new runtime and lots and lots of functionality for dealing with the web server itself, such as user/role management, session management, etc.

In the meantime, I'm doing a new 2.06 Build 6 that will be out tomorrow (Tuesday, the 12th).  This will include mostly minor fixes, but also an important fix for a bug in the inertia scrolling.

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Is SSL support still far away from release?

Paul.



Tim Young [Elevate Software] wrote:

I know things have been very quiet lately, so I just wanted to drop a quick progress update on 2.07.  Progress is going well, but a little slower than expected.  Combined with a bit of a late start in August, it looks like it will be mid-October for the first beta.

As previously mentioned, 2.07 will include:

- SSL and GZip support in the EWB Web Server
- Server-side application execution in the EWB Web Server
- Server-side application creation in the EWB IDE

The server-side application support includes a new runtime and lots and lots of functionality for dealing with the web server itself, such as user/role management, session management, etc.

In the meantime, I'm doing a new 2.06 Build 6 that will be out tomorrow (Tuesday, the 12th).  This will include mostly minor fixes, but also an important fix for a bug in the inertia scrolling.

Tim Young
Elevate Software
www.elevatesoft.com

<< Tim Young [Elevate Software] wrote:
Combined with a bit of a late start in August, it looks like it will be mid-October for the first beta.>>

Hi Tim, did you you reach a point with the new version 2.0.7 (or is it 3.0.0) where you could release a BETA BUILD? I am not seeing a public announcement of such a build, so I presume not.

I am asking because we have reached a point in our first project where we need to make some serious platform decisions for the server side. You have several nice enhancements planned for the EWB Server, and playing with a BETA BUILD (even if imperfect or incomplete) which will make the decision much easier. And of course it will also enable to give feedback before features are frozen.

Thanks,
Stephen

Stephen,

<< Hi Tim, did you you reach a point with the new version 2.0.7 (or is it 3.0.0) where you could release a BETA BUILD? I am not seeing a public announcement of such a build, so I presume not. >>

It's EWB 3 now, and no, the beta isn't available yet.  The scope has increased a bit, and that has blown the schedule up quite a bit.  Right now it looks like I might be able to have the beta available by the end of March, but that's pretty optimistic and I need to spend some more time on the run-time for the server-side applications.  The good thing is that I can add run-time functionality while the beta is being used, but there's a baseline there that needs to be present, otherwise the server-side applications won't be of much use for anything other than "Hello World".

<< I am asking because we have reached a point in our first project where we need to make some serious platform decisions for the server side. You have several nice enhancements planned for the EWB Server, and playing with a BETA BUILD (even if imperfect or incomplete) which will make the decision much easier. And of course it will also enable to give feedback before features are frozen. >>

If you want to ask any questions about what's in the new web server, feel free to ask and I'll be happy to tell you if the feature exists or not, or how something works.

Mark Brooks and I have been discussing the security via email, and here's a description that I sent Mark - he was asking about session tokens and how the authentication worked:

================

Session IDs are used as authentication tokens, and are cryptographically-generated (Windows Crypto API) random bits of data of a length that you can configure (the default is 32 bytes).  The session IDs are passed back to the browser as an HTTP-only, securely-matched cookie that expires within a sliding window that you can also configure (the default is 30 minutes).  The sliding window is determined by the last request using the session ID.  There is a "keep-alive" URL in the web server now that a client can use to refresh the sliding window periodically and keep the session alive, so there shouldn't be any issues with sessions expiring in the middle of being actively used.   Expired sessions are cleaned up in a sweep that is controlled by an interval that you can configure (default is 5 minutes).

A user *must* authenticate before they can do anything with non-static content, and they are given a session ID during the authentication process.  There is a configuration property for the number of times that a user can attempt a failed authentication before their account is locked (the default is 10), with a configuration option to specify how long such a lockout will remain (default is 5 minutes).  In addition, a history of all password hashes used by the user account is kept to ensure that passwords are not re-used at any time (this *isn't* configurable, but I can make it be so).  Also, users can be manually locked out for *any* length of time by an administrator (granted the Administrator role, see below).

Passwords are hashed with SHA-256, by default, using a password salt that is cryptographically-generated using a specified length that you can configure (default is 16 bytes of data).  But, you can also specify SHA-512 for passwords.

The security, in general, is role-based, with users assigned roles and roles assigned privileges.  All of the roles and privileges are user-defined, with some system-defined roles/privileges that cannot be removed that are used for controlling access to the system security and data.  Users and roles can be activated/deactivated, so one can "take something off-line" without necessarily deleting it, which is good for when a user role is being referenced elsewhere, but you don't want it used for some reason.

All session activity is logged, up and above the general HTTP logging that is done at the request/response level, so that there is a complete audit trail.  This is all very important for HIPAA in the US and PCI compliance, in general.

In the server applications and native modules, server-side code can query the web server for the effective roles/privileges for the session, as well as check to see if the current session user has a given role/privilege granted.

The way the server applications and native modules work is cool also - they now need to be updateable while they are being used, so there's a versioning mechanism in the EWB Web Server that can handle keeping an old version of a server application or module around and loaded until the last session is done using it, and then removing it.

Most importantly, *all* of this can be done via a web API, so you can configure this all remotely using the EWB IDE or an EWB application.  However, right now the EWB Web Server doesn't *enforce* https for this API, but I'm seriously considering doing so for any usage outside of the IDE and the internal web server.

As far as the GDPR is concerned, there are user IDs, but apart from that there is no personal information other than an optional Name and EmailAddress (for abuse of service issues, which are a legitimate usage under GDPR).

====================

Tim Young
Elevate Software
www.elevatesoft.com