The LedgerSMB development team is happy to announce yet another new
version of its open source ERP and accounting application.
This release contains the following fixes and improvements:
Changelog for 1.7.9
* Fix authentication issue due to inconsistent cookie handling
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.7.9/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.7.9
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.9
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.7.9
These are the sha256 checksums of the uploaded files:
44383e829c460ef5a567e03e3a480c4c12083a0f3611f616b4cb37c9026372d4 ledgersmb-1.7.9.tar.gz
b3b5c5123ad6994af2e6975df0efe44266b9773a4a3e39a37895ba59f13072b2 ledgersmb-1.7.9.tar.gz.asc
The LedgerSMB development team is happy to announce yet another new
version of its open source ERP and accounting application.
This release contains the following fixes and improvements:
Changelog for 1.6.19
* Fix authentication issue due to inconsistent cookie handling (Erik H)
Erik H is Erik Huelsmann
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.6.19/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.6.19
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.19
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.6.19
These are the sha256 checksums of the uploaded files:
17d784a326e7963cd048e05c32d9a65ba56b43734ed72b6266d866456f225a6f ledgersmb-1.6.19.tar.gz
2822affae38bfd27c74812288bd33bac129b00c1890b2232d28794673c40bcf8 ledgersmb-1.6.19.tar.gz.asc
Hi,
As part of my preparations to introduce web services, I've found that many
web APIs provide two ways to authenticate: (a) a session cookie which can
be obtained by "logging in", or (b) an "API key" ; either the API key or
the session cookie is then provided with each request to the API,
authenticating the request with the session and/or user. It should be noted
that neither requests providing an API key nor those providing a session
cookie contain further credentials.
For our (API) authentication, ideally, I'd like to be able to provide both
the "api key" and the "session cookie" patterns for request authorization.
Additionally, I'd like session authentication to be available using:
- Username & password (preferably through CRAM-SHA2 or higher SHA)
* Note that in this scenario, the password validation could be anything;
even a Kerberos or LDAP server
- WebAuth / FIDO2
- OAuth2
- Client certificate
- (and more, if we come up with those)
== The Problem ==
Our current authentication setup requires plain text username and password
on the initial login and each further request. We currently use basic auth
to supply these values. In addition, we use a session cookie, but that only
serves to validate the session. Thus every request currently requires the
username, password and session cookie. The username and password are
required because those are used to set up the database connection at the
start of the request handling.
Most of the authentication systems above don't maintain a username/password
combination visible to our server. By consequence, I'm looking for ways to
eliminate the need for the username+password in the Web request. Also, if
we'd want to use "API key" type authentication, that API key would need to
hold in it (encrypted, but decryptable to the server) the username and
password in order to be able to log into the database.
Note that the previous sentence explicitly states "in the Web request":
ideally, LedgerSMB authentication can happen on two different levels -- the
web request level and the database connection level. Basically, I'd like to
start making the distinction between the web request authentication and the
database authentication in such a way that our database authorization
(access control) remains PostgreSQL-role-based (that is: doesn't change
from the current model).
== The Proposal ==
My current idea is to separate the web authentication from the database
authentication. The web application would use a generic user to set up the
database connection, switching the session authorization to the role
associated with the user, as if the user had logged in directly on the
database. Technically, this is achieved by the Pg command 'SET SESSION
AUTHORIZATION = username'. This means that once the session has been
verified (either through the API key provided or the session cookie),
authorization can be switched to the (web)authenticating user and regular
processing (as we know it today) can continue.
This solution using the session authorization is very similar to what the
Graphile (graphile.org) project uses [they use SET ROLE instead of SET
SESSION AUTHORIZATION -- there are subtle differences between their
approach and my proposal].
The solution has the benefit of supporting direct connections to the
database as they are today with all methods built into PostgreSQL, adding
into the mix a second set of authorization options better suited to a web
authentication scenario.
== The Request ==
Please comment on the above to get a good common understanding of what I'm
describing and the best possible implementation at that.
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hi,
I've been working on and submitting ports, but there has been
port-a-thons and hackathons right as I submit stuff. I took a long
holiday this year as it rained and snowed almost non-stop.
I also got delayed by my laptop having some kind of problem.
I couldn't fix it, but it works fine with an older version of OpenBSD
and I'm just running -current on my servers and doing this work there.
I submitted PGObject a while back. Someone had to update the
postgresql database test module for the testing to work.
Then I realized looking closer that it does the same thing I do, it gets
$dbh from elsewhere.
I'm looking over the rest of these modules, but so far I am seeing
mostly the same.
Except for DBAdmin. So far running the database tests for that one are
failing, including from the actual Perl build.
I'm not sure that I am doing the tests properly. I'm going to ask and
look at other ports in OpenBSD to see if I'm doing the tests correctly.
We never directly use the Perl build for testing. We have a PostgreSQL
testing module for that.
I just saw mention of PGObject in github email.
What does that mean?
I haven't had a chance to look in the LedgerSMB code at the spots where
those modules are being used.
Otherwise, I've done a lot of work getting the modules ready. Submitted
some and I've got several more ready to submit.
I do have one problem. Several of the modules don't have DESCRIPTIONS.
I already have one Plack that I have been asked to give a better
description before it can be accepted (the encoding one).
Also, the various PGObject-* are really bad on that. Is there any way to
come up with something more official for the group? Perhaps like an
overall description for the group with a detail for how each one fits
into the group?
Maybe something like:
The PGObject set does ...
and this module carries out the ...
That would be extremely helpful. Once in the ports tree, no problems.
--
Chris Bennett
