- devel - lists.freelock.com

LedgerSMB 1.8.18 released
by Erik Huelsmann 23 Aug '21

23 Aug '21

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains three fixes for security vulnerabilities. Users are urged to upgrade as soon as possible. Special thanks go to "ranjit-git", and sudheendra17, users of the https://huntr.dev/ platform, for disclosing these issues responsibly to the development team. And to the platform itself for sponsoring the work of these researchers. This release contains the following fixes and improvements: Changelog for 1.8.18 * Check whether HTML comes from a valid source; CVE-2021-3693 * Apply HTML escaping on error messages; CVE-2021-3694 (#5754) * Fix several issues in `bin/prepare-company-database` (#5769) * Prevent the application being wrapped in a frame; CVE-2021-3731 For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.8.18/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.8.18 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.8.18 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.8.18 These are the sha256 checksums of the uploaded files: c3ed50b78a0cebc6ef7edfab6a5b1c7b6b5b2f5545bf2d680ad6c3f6cbca5be2 ledgersmb-1.8.18.tar.gz 133fae3563fa1be3eb4cd48ec06347187ba165bbeeb854c92ed03d9c08111ae0 ledgersmb-1.8.18.tar.gz.asc

1 0

ledgersmb_1.6.9+ds-1+deb10u2_amd64.changes ACCEPTED into oldstable-proposed-updates->oldstable-new
by Debian FTP Masters 23 Aug '21

23 Aug '21

Mapping oldstable-security to oldstable-proposed-updates. Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Sun, 22 Aug 2021 20:54:25 +0200 Source: ledgersmb Architecture: source Version: 1.6.9+ds-1+deb10u2 Distribution: buster-security Urgency: medium Maintainer: LedgerSMB Core Team <devel(a)lists.ledgersmb.org> Changed-By: Moritz Muehlenhoff <jmm(a)debian.org> Changes: ledgersmb (1.6.9+ds-1+deb10u2) buster-security; urgency=medium . * Fix CVE-2021-3731, thanks for Erik Huelsmann Checksums-Sha1: 81dff0043e075588fffb234efda4b78b641f5449 3265 ledgersmb_1.6.9+ds-1+deb10u2.dsc 851b39c25748d2a780895f8c2a450b94e53ac31e 37796 ledgersmb_1.6.9+ds-1+deb10u2.debian.tar.xz a3db94b57cf7fcdedaf9197ed8be469f2e673934 15094 ledgersmb_1.6.9+ds-1+deb10u2_amd64.buildinfo Checksums-Sha256: bc167a97c2e63a4c72882bb7d82a39cf79b56f51c3dabd330713922a5b4c7c2d 3265 ledgersmb_1.6.9+ds-1+deb10u2.dsc aef28aa91470f89a51ad87f14e8f6da13c9a79340fd96124a0e5f5c77ab80120 37796 ledgersmb_1.6.9+ds-1+deb10u2.debian.tar.xz bff4d79e7d88353b98a696bd2b6f16b3064c3e3716c4b401a4e19375c383dd5c 15094 ledgersmb_1.6.9+ds-1+deb10u2_amd64.buildinfo Files: 0fd6e172a26caf3ba19491665415ad32 3265 web optional ledgersmb_1.6.9+ds-1+deb10u2.dsc 630ed153ca2cbdddaffee480eead3ea7 37796 web optional ledgersmb_1.6.9+ds-1+deb10u2.debian.tar.xz 8349333bfcf81badb8b633d401c949e6 15094 web optional ledgersmb_1.6.9+ds-1+deb10u2_amd64.buildinfo -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEtuYvPRKsOElcDakFEMKTtsN8TjYFAmEiol4ACgkQEMKTtsN8 Tjaj6Q//emxljrNJ/qkzrLegCv8Cx/cprXTvhilk2ql45OI74n4hNeYV6LLoVJWs T2VaG+QQSjHUXA18YSWhumHJdQc15Z5FlGD1QxgDuQh9yzLkonXthI6vykGbDsSs 1Fb6FYHBXphz5q5rLbFdqlaoVEcalKJpaMPNDZxh61Z9KjAiOIiUmPTKDxecz8Ro nL2E6UjyoKeX64CtVGT/jd2QOFXK6ego21oYFZZxGsHU5hPwqlC5f1aYXec6nBNz PGMSsvuQoBkVzkjjeqpELeu+TzniVD3savNNYLwbEB0ghEFsVJV7AvREkAG0/6WD Gi1+f3WG//WJfqLTQqniVw5tDEkso7fSJXPkXp2hv1yQ4fCBnGbfGtEw5sQnMIKe 5ZjmhNg9SbWXYP7Q3s9j/IFXsgXhfdumzYW/ym+TIcOEcXtPewbJ4qS9YFy3+4vR aksSOMqeOQBYYS8cWoSk9xlt/01MU2XTrxlIMPZbKztoE5UbYi2eYTDSu7gjc3Rn 6AqcaU1vIkcTEC/2BpnQJwizIPpwTyN86INWMa3XSFKMIy1HAJ41zWEDN/BOoAI5 DDe0vGkjqs3o6JQ5rRfxXq9Y3PkXiWmvI2FKRsVVNPZn0yao4TCEAKVWZKc8Xo9s MtA6N4bnky8RDQPsmIDwKd9O8BvuN9VAkf17V8vgEYx89JMxooA= =hShF -----END PGP SIGNATURE----- Thank you for your contribution to Debian.

1 0

ledgersmb_1.6.9+ds-1+deb10u1_amd64.changes ACCEPTED into oldstable-proposed-updates->oldstable-new
by Debian FTP Masters 23 Aug '21

23 Aug '21

Mapping oldstable-security to oldstable-proposed-updates. Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Thu, 19 Aug 2021 21:04:51 +0200 Source: ledgersmb Architecture: source Version: 1.6.9+ds-1+deb10u1 Distribution: buster-security Urgency: medium Maintainer: LedgerSMB Core Team <devel(a)lists.ledgersmb.org> Changed-By: Moritz Muehlenhoff <jmm(a)debian.org> Changes: ledgersmb (1.6.9+ds-1+deb10u1) buster-security; urgency=medium . * Fix CVE-2021-3693 and CVE-2021-3694, thanks to Erik Huelsmann Checksums-Sha1: 3669a256a11320037b67c0b2f129c4e691ee0325 3265 ledgersmb_1.6.9+ds-1+deb10u1.dsc efa19d0a485ff3b7795b8ce965fdedb6ad37d20e 1961328 ledgersmb_1.6.9+ds.orig.tar.xz 872d9d026f228229d0208216a7a2f0e13094aa30 37608 ledgersmb_1.6.9+ds-1+deb10u1.debian.tar.xz ca78d7a16fcae63d1d4d1178b4bf8598bf2f690a 15094 ledgersmb_1.6.9+ds-1+deb10u1_amd64.buildinfo Checksums-Sha256: 0ae418267d121a9a7d08723ca5333794a6196891613760355c038765dbb1f894 3265 ledgersmb_1.6.9+ds-1+deb10u1.dsc 7e29702482dd84ab30caf176bbdf56b7069db488b36c921b4ff57878ab1b579b 1961328 ledgersmb_1.6.9+ds.orig.tar.xz 4e00afff36715a9f43e3e0b3ddbcb4f17844c2df5ff8da0b36d10e638bceff29 37608 ledgersmb_1.6.9+ds-1+deb10u1.debian.tar.xz 0dbcaabcf453d5dbf3bd67c84539b9aabbafa7f050df75d64ff0b2d2bcf38bec 15094 ledgersmb_1.6.9+ds-1+deb10u1_amd64.buildinfo Files: 3830971b3cefbb644b940d61ba4ed749 3265 web optional ledgersmb_1.6.9+ds-1+deb10u1.dsc 1502debde292e73ab9e27e35c2f9fc23 1961328 web optional ledgersmb_1.6.9+ds.orig.tar.xz 11c73d8120d2d51a761d5b550da6c7ab 37608 web optional ledgersmb_1.6.9+ds-1+deb10u1.debian.tar.xz e1c38e333c7f604c155f74a2dcca7b76 15094 web optional ledgersmb_1.6.9+ds-1+deb10u1_amd64.buildinfo -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEtuYvPRKsOElcDakFEMKTtsN8TjYFAmEerfQACgkQEMKTtsN8 TjYzBhAAl04KouFB15/h6vQx9IN5x4eD6CEmJ22KkeDMiw1J95b34aMPubVT4oKa sGp4y8DMeRF68Etz5FIKt3yiQm21u8/znwgXbKjHW4AsPTn0AkLMJgzmpGpauKHG 1MH3+8JF8SS5J5h4IXX7fQ4aZSz1EEaBZ7A9m/aNt2c5pQqhr58DtMV05ShTeA0j rMCevaS6qNCIwWNiCAuAylvGNMpMFtSHrrYSIX2aiBF8gdPv4TXX4FxeZhH1wYWp qQh4ugZzDP3PBUA8zU6KJtc5HR60xG+4ZDQn+7oviH1984kRpX6St4IvzPaBjd1f c1bfWAvdF84+Io1r0rSu6dshxqXALvpQYzyQe5rRgSic7AMhDahs9fBDWCW5iQ6K NoZ5f5OWWRb1uHbZrPXz/YIb/IrAw3HF2sfAZNaNXFT4wsn++urAoJ9m+sEtFBI5 +EJ9o+YrzGRPU4Kjj9e619u+VkhMdW4LEJKZzpqQyNug3we61ryyqLb4b0OizDsy xMb9DqbtxDpCMqIaTyzUvMyHdHToWhPir/K9fIo0X35Mbvmo6H/0f0jh8qdEOwp0 KG6+7qysj56hWrJnMUKNMkeGRRO36QDtH7SEGu/1CndYX1/QWGMqxYJ4e2FWc7O5 mnGufYVZ8aOIxgrHS5vFokpJ3iIXgDE69Wcnk/fHPHTXCs9H70Q= =hb6q -----END PGP SIGNATURE----- Thank you for your contribution to Debian.

1 0

LedgerSMB 1.7.33 released
by Erik Huelsmann 23 Aug '21

23 Aug '21

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains three fixes for security vulnerabilities. Users are urged to upgrade as soon as possible. Special thanks go to "ranjit-git", and sudheendra17, users of the https://huntr.dev/ platform, for disclosing these issues responsibly to the development team. And to the platform itself for sponsoring the work of these researchers. This release contains the following fixes and improvements: Changelog for 1.7.33 * Check whether HTML comes from a valid source; CVE-2021-3693 * Apply HTML escaping on error messages; CVE-2021-3694 (#5766) * Prevent the application being wrapped in a frame; CVE-2021-3731 * Align filters between UI and the database on draft transaction search (#5693) * Correctly present manual tax and invoice total on reversing invoice (#5721) * Repeatedly saving a draft invoice pops up an SQL error (#5679) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.33/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.33 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.33 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.33 These are the sha256 checksums of the uploaded files: 15dcc79a42fd17f12d01e1cc4b36ddd25e8dbe776ffe1b9867a1ad9e42bfabc0 ledgersmb-1.7.33.tar.gz 73eadc3bf2c2b3d2abeabe52ccc3db03dd5e46599d4a84a3a72ef10105d6ab36 ledgersmb-1.7.33.tar.gz.asc

1 0

[SECURITY] Advisory for clickjacking vulnerability CVE-2021-3731
by Erik Huelsmann 23 Aug '21

23 Aug '21

On August 20th, the LedgerSMB project was advised of a security vulnerability in the code. Please see below our security advisory. Insufficient protection against 'clickjacking' Summary: ======== LedgerSMB does not sufficiently guard against being wrapped by other sites, making it vulnerable to 'clickjacking. This allows an attacker to trick a targetted user to execute unintended actions. Known vulnerable: ================= All of: - 1.1.0 upto 1.1.12 (including) - 1.2.0 upto 1.2.26 (including) - 1.3.0 upto 1.3.47 (including) - 1.4.0 upto 1.4.42 (including) - 1.5.0 upto 1.5.30 (including) - 1.6.0 upto 1.6.33 (including) - 1.7.0 upto 1.7.32 (including) - 1.8.0 upto 1.8.17 (including) Known fixed: ============ - 1.7.33 - 1.8.18 Details: ======== In a clickjacking attack, an attacker (invisibly) wraps the vulnerable site in his own site, carefully placing elements of his own site over elements of the wrapped site, tricking the user into performing unintended actions on the vulnerable site. More information on clickjacking is on the OWASP page at https://owasp.org/www-community/attacks/Clickjacking The lack of protection dates back to version 1.0, although it must be noted that mitigation measures were first available in browsers as of 2011 -- the year of the release of 1.3.0. Severity: ========= CVSSv3.1 Base Score: 5.9 (Medium) CVSSv3.1 Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N Recommendations: ================ We recommend all users to upgrade to known-fixed versions. Versions prior to 1.7 are end-of-life and will not receive security fixes from the LedgerSMB project. Users who cannot upgrade, may apply the included patches or are advised to contact a vendor for custom support. As a workaround, administrators may configure their webservers to add the Content-Security-Policy header as documented in the content security policy site at https://content-security-policy.com/#server. References: =========== CVE-2021-3731 (LedgerSMB) https://ledgersmb.org/cve-2021-3731-clickjacking https://huntr.dev/bounties/5664331d-f5f8-4412-8566-408f8655888a/ Reported by: ============ sudheendra17, user of the huntr.dev platform Patches: ======== Patch for LedgerSMB 1.8 (1.8.0 upto 1.8.17, including): ------------------------------------------------------- [[[ diff --git a/lib/LedgerSMB/PSGI.pm b/lib/LedgerSMB/PSGI.pm index b0b20a95b..a4785a9f1 100644 --- a/lib/LedgerSMB/PSGI.pm +++ b/lib/LedgerSMB/PSGI.pm @@ -122,6 +122,9 @@ sub old_app { return Plack::Util::response_cb( $handler->($env), sub { + Plack::Util::header_set($_[0]->[1], + 'Content-Security-Policy', + q{frame-ancestors 'self'}); if (not Plack::Util::header_exists($_[0]->[1], 'X-LedgerSMB-App-Content')) { Plack::Util::header_push($_[0]->[1], @@ -179,6 +182,9 @@ sub psgi_app { } }; + Plack::Util::header_set($res->[1], + 'Content-Security-Policy', + q{frame-ancestors 'self'}); return $res; } ]]] Patch for LedgerSMB 1.7 (1.7.0 upto 1.7.32, including): ------------------------------------------------------- [[[ diff --git a/lib/LedgerSMB/PSGI.pm b/lib/LedgerSMB/PSGI.pm index ec8be07f1..bcb478524 100644 --- a/lib/LedgerSMB/PSGI.pm +++ b/lib/LedgerSMB/PSGI.pm @@ -91,6 +91,9 @@ sub old_app { return Plack::Util::response_cb( $handler->(@_), sub { + Plack::Util::header_set($_[0]->[1], + 'Content-Security-Policy', + q{frame-ancestors 'self'}); if (not Plack::Util::header_exists($_[0]->[1], 'X-LedgerSMB-App-Content')) { Plack::Util::header_push($_[0]->[1], @@ -159,6 +162,9 @@ sub psgi_app { } }; + Plack::Util::header_set($res->[1], + 'Content-Security-Policy', + q{frame-ancestors 'self'}); return $res; } ]]] -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

[SECURITY] Advisory for cross site scripting security vulnerability CVE-2021-3694
by Erik Huelsmann 23 Aug '21

23 Aug '21

On August 4th, the LedgerSMB project was advised of a security vulnerability in the code. Please see below our security advisory. Reflected cross-site scripting of authenticated users in LedgerSMB Summary: ======== LedgerSMB does not sufficiently HTML-encode error messages sent to the browser. By sending a specially crafted URL to an authenticated user, this flaw can be abused for remote code execution and information disclosure. Known vulnerable: ================= All of: - 1.1.0 upto 1.1.12 (including) - 1.2.0 upto 1.2.26 (including) - 1.3.0 upto 1.3.47 (including) - 1.4.0 upto 1.4.42 (including) - 1.5.0 upto 1.5.30 (including) - 1.6.0 upto 1.6.33 (including) - 1.7.0 upto 1.7.32 (including) - 1.8.0 upto 1.8.17 (including) Known fixed: ============ - 1.7.33 - 1.8.18 Details: ======== When encountering an error, LedgerSMB sends the user feedback which may include user-provided input. This input was not sufficiently sanitized before being included in the error report. This allows an attacker inject a script in the error response page by send a specially crafted URL to an authenticated user. As the error page itself does not contain any sensitive information, a sophisticated payload in addition to targetting a sufficiently privileged user, is required for information disclosure. Proper audit control and separation of duties limit Integrity impact of the attack vector. The vulnerable code to provide this user-feedback dates back to version 1.0. Please note that not error messages are vulnerable to this attack as not all messages report the problematic input to the user. Severity: ========= CVSSv3.1 Base Score: 8.2 (High) CVSSv3.1 Vector: AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N Recommendations: ================ We recommend all users to upgrade to known-fixed versions. Versions prior to 1.7 are end-of-life and will not receive security fixes from the LedgerSMB project. Users who cannot upgrade, may apply the included patches or are advised to contact a vendor for custom support. There are no workarounds available for this vulnerability. References: =========== CVE-2021-3694 (LedgerSMB) https://ledgersmb.org/cve-2021-3694-cross-site-scripting https://huntr.dev/bounties/ef7f4cf7-3a81-4516-b261-f5b6ac21430c/ Reported by: ============ ranjit-git, user of the huntr.dev platform Patches: ======== Patch for LedgerSMB 1.8 (1.8.0 upto 1.8.17, including): ------------------------------------------------------- [[[ diff --git a/lib/LedgerSMB/PSGI/Util.pm b/lib/LedgerSMB/PSGI/Util.pm index 11c01918f..bf443d886 100644 --- a/lib/LedgerSMB/PSGI/Util.pm +++ b/lib/LedgerSMB/PSGI/Util.pm @@ -24,6 +24,7 @@ use strict; use warnings; use Carp; +use HTML::Escape; use HTTP::Status qw( HTTP_OK HTTP_INTERNAL_SERVER_ERROR HTTP_SEE_OTHER HTTP_BAD_REQUEST ); @@ -41,7 +42,7 @@ Returns a standard error representation for HTTP status 500 sub internal_server_error { - my ($msg, $title, $company, $dbversion) = @_; + my ($msg, $title, $company, $dbversion) = map { escape_html($_ // '') } @_; $title //= 'Error!'; $msg =~ s/\n/<br>/g; diff --git a/old/lib/LedgerSMB/oldHandler.pm b/old/lib/LedgerSMB/oldHandler.pm index 1db966406..848eeb75c 100644 --- a/old/lib/LedgerSMB/oldHandler.pm +++ b/old/lib/LedgerSMB/oldHandler.pm @@ -57,6 +57,7 @@ use LedgerSMB::Sysconfig; use Cookie::Baker; use Digest::MD5; +use HTML::Escape; use Log::Log4perl; use Try::Tiny; @@ -184,14 +185,17 @@ sub handle { sub _error { my ($form, $msg, $status) = @_; $msg = "? _error" if !defined $msg; + my $html_msg = escape_html($msg); + my $html_dbversion = escape_html($form->{dbversion}); + my $html_company = escape_html($form->{company}); $status = 500 if ! defined $status; print qq|Status: $status ISE Content-Type: text/html; charset=utf-8 <html> -<body><h2 class="error">Error!</h2> <p><b>$msg</b></p> -<p>dbversion: $form->{dbversion}, company: $form->{company}</p> +<body><h2 class="error">Error!</h2> <p><b>$html_msg</b></p> +<p>dbversion: $html_dbversion, company: $html_company</p> </body> </html> |; ]]] Patch for LedgerSMB 1.7 (1.7.0 upto 1.7.32, including): ------------------------------------------------------- [[[ diff --git a/lib/LedgerSMB/PSGI/Util.pm b/lib/LedgerSMB/PSGI/Util.pm index 2d6195d69..b716a01c4 100644 --- a/lib/LedgerSMB/PSGI/Util.pm +++ b/lib/LedgerSMB/PSGI/Util.pm @@ -24,6 +24,7 @@ use strict; use warnings; use Carp; +use HTML::Escape; use HTTP::Status qw( HTTP_OK HTTP_INTERNAL_SERVER_ERROR HTTP_SEE_OTHER HTTP_UNAUTHORIZED ); @@ -41,7 +42,7 @@ Returns a standard error representation for HTTP status 500 sub internal_server_error { - my ($msg, $title, $company, $dbversion) = @_; + my ($msg, $title, $company, $dbversion) = map { escape_html($_ // '') } @_; $title //= 'Error!'; $msg =~ s/\n/<br>/g; diff --git a/old/bin/old-handler.pl b/old/bin/old-handler.pl index 24fa7a0a0..87864fc7e 100644 --- a/old/bin/old-handler.pl +++ b/old/bin/old-handler.pl @@ -187,14 +187,16 @@ $form->{dbh}->disconnect() if defined $form->{dbh}; sub _error { my ($form, $msg, $status) = @_; $msg = "? _error" if !defined $msg; + my $html_msg = escape_html($msg); + my $html_dbversion = escape_html($form->{dbversion}); + my $html_company = escape_html($form->{company}); $status = 500 if ! defined $status; print qq|Status: $status ISE Content-Type: text/html; charset=utf-8 - <html> -<body><h2 class="error">Error!</h2> <p><b>$msg</b></p> -<p>dbversion: $form->{dbversion}, company: $form->{company}</p> +<body><h2 class="error">Error!</h2> <p><b>$html_msg</b></p> +<p>dbversion: $html_dbversion, company: $html_company</p> </body> </html> |; ]]] -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

[SECURITY] Advisory for cross site scripting security vulnerability CVE-2021-3693
by Erik Huelsmann 23 Aug '21

23 Aug '21

On August 4th, the LedgerSMB project was advised of a security vulnerability in the code. Please see below our security advisory. DOM cross-site scripting of authenticated users in LedgerSMB Summary: ======== LedgerSMB does not check the origin of HTML fragments merged into the browser's DOM. By sending a specially crafted URL to an authenticated user, this flaw can be abused for remote code execution and information disclosure. Known vulnerable: ================= All of: - 1.5.0 upto 1.5.30 (including) - 1.6.0 upto 1.6.33 (including) - 1.7.0 upto 1.7.32 (including) - 1.8.0 upto 1.8.17 (including) Known fixed: ============ - 1.7.33 - 1.8.18 Details: ======== LedgerSMB uses the URL's hash fragment (the part after the '#'-sign) to store which screen the user is on, for the purpose of history navigation (the back button). The hash fragment is assumed to be a URL that is part of the web application's URL space. This assumption is not verified. This allows an attacker inject a script into the page by send a specially crafted URL to an authenticated user. As the process of loading the attack payload overwrites any content in the main window, the attack by itself does not expose sensitive information; a sophisticated payload in addition to targetting a sufficiently privileged user, is required for information disclosure. Proper audit control and separation of duties limit Integrity impact of the attack vector. The vulnerable code dates back to version 1.5 when LedgerSMB moved to the Single Page Application (SPA) model for web applications. Severity: ========= CVSSv3.1 Base Score: 7.1 (High) CVSSv3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N Recommendations: ================ We recommend all users to upgrade to known-fixed versions. Versions prior to 1.7 are end-of-life and will not receive security fixes from the LedgerSMB project. Users who cannot upgrade, may apply the included patches or are advised to contact a vendor for custom support. There are no workarounds available for this vulnerability. References: =========== CVE-2021-3693 (LedgerSMB) https://ledgersmb.org/cve-2021-3693-cross-site-scripting https://huntr.dev/bounties/daf1384d-648a-43fd-9b35-5c37d8ead667/ Reported by: ============ ranjit-git, user of the huntr.dev platform Patches: ======== Patch for LedgerSMB 1.8 (1.8.0 upto 1.8.17, including): ------------------------------------------------------- [[[ diff --git a/UI/js-src/lsmb/MainContentPane.js b/UI/js-src/lsmb/MainContentPane.js index 9c0d6113c..ebfa36f05 100644 --- a/UI/js-src/lsmb/MainContentPane.js +++ b/UI/js-src/lsmb/MainContentPane.js @@ -7,8 +7,8 @@ define([ "dojo/dom-style", "dojo/_base/lang", "dojo/promise/Promise", + "dojo/Deferred", "dojo/promise/all", - "dojo/request/xhr", "dojo/query", // "dojo/request/iframe", "dojo/dom-class" @@ -19,12 +19,21 @@ define([ domStyle, lang, Promise, + Deferred, all, - xhr, query, // iframe, domClass ) { + var docURL = new URL(document.location); + var domReject = function (request) { + return ( + request.getResponseHeader("X-LedgerSMB-App-Content") !== "yes" || + (request.getResponseHeader("Content-Disposition") || "").startsWith( + "attachment" + ) + ); + }; return declare("lsmb/MainContentPane", [ContentPane], { last_page: null, interceptClick: null, @@ -74,17 +83,62 @@ define([ ); }, load_form: function (url, options) { + var tgt = new URL(url, docURL); + if (tgt.origin !== docURL.origin) { + return new Deferred().resolve(); + } + var self = this; self.fade_main_div(); - return xhr(url, options).then( - function (doc) { - self.hide_main_div(); - self.set_main_div(doc); - }, - function (err) { - self.show_main_div(); - self.report_request_error(err); - } + var req = new XMLHttpRequest(); + var dfd = new Deferred(function () { + req.abort(); + }); + try { + req.open(options.method || "GET", tgt); + var headers = options.headers; + for (var hdr in headers || {}) { + req.setRequestHeader(hdr, headers[hdr]); + } + if ( + options.data && + !(options.data instanceof FormData) && + !headers["Content-Type"] + ) { + req.setRequestHeader( + "Content-Type", + "application/x-www-form-urlencoded" + ); + } + req.setRequestHeader("X-Requested-With", "XMLHttpRequest"); + req.addEventListener("load", function () { + dfd.resolve(req); + }); + req.addEventListener("error", function () { + dfd.reject(req); + }); + req.send(options.data || ""); + } catch (e) { + dfd.reject(e); + } + + return dfd.then( + function (request) { + if (domReject(request)) { + return self.show_main_div(); + } + + self.hide_main_div(); + return self.set_main_div(request.response); + }, + function (request) { + if (domReject(request)) { + return self.show_main_div(); + } + + self.show_main_div(); + return self.report_request_error({ err: request }); + } ); }, download_link: function (/*href*/) { diff --git a/lib/LedgerSMB/Middleware/DynamicLoadWorkflow.pm b/lib/LedgerSMB/Middleware/DynamicLoadWorkflow.pm index 99a964548..07f2feb34 100644 --- a/lib/LedgerSMB/Middleware/DynamicLoadWorkflow.pm +++ b/lib/LedgerSMB/Middleware/DynamicLoadWorkflow.pm @@ -29,6 +29,7 @@ use HTTP::Status qw/ HTTP_REQUEST_ENTITY_TOO_LARGE /; use List::Util qw{ none any }; use Module::Runtime qw/ use_module /; use Plack::Request; +use Plack::Util; use Plack::Util::Accessor qw( script script_name module ); use LedgerSMB::PSGI::Util; @@ -91,7 +92,15 @@ sub call { $env->{'lsmb.script_name'} = $self->script_name; $env->{'lsmb.action'} = $action; $env->{'lsmb.action_name'} = $action_name; - return $self->app->($env); + return Plack::Util::response_cb( + $self->app->($env), + sub { + if (not Plack::Util::header_exists($_[0]->[1], + 'X-LedgerSMB-App-Content')) { + Plack::Util::header_push($_[0]->[1], + 'X-LedgerSMB-App-Content', 'yes'); + } + }); } diff --git a/lib/LedgerSMB/PSGI.pm b/lib/LedgerSMB/PSGI.pm index 26b4ec6b3..b0b20a95b 100644 --- a/lib/LedgerSMB/PSGI.pm +++ b/lib/LedgerSMB/PSGI.pm @@ -119,7 +119,15 @@ sub old_app { my $env = shift; local $psgi_env = $env; - return $handler->($env); + return Plack::Util::response_cb( + $handler->($env), + sub { + if (not Plack::Util::header_exists($_[0]->[1], + 'X-LedgerSMB-App-Content')) { + Plack::Util::header_push($_[0]->[1], + 'X-LedgerSMB-App-Content', 'yes'); + } + }); } } ]]] Patch for LedgerSMB 1.7 (1.7.0 upto 1.7.32, including): ------------------------------------------------------- [[[ diff --git a/UI/js-src/lsmb/MainContentPane.js b/UI/js-src/lsmb/MainContentPane.js index 17ac8d391..5bc1bd4fa 100644 --- a/UI/js-src/lsmb/MainContentPane.js +++ b/UI/js-src/lsmb/MainContentPane.js @@ -6,6 +6,7 @@ define([ "dojo/dom-style", "dojo/_base/lang", "dojo/promise/Promise", + "dojo/Deferred", "dojo/on", "dojo/hash", "dojo/promise/all", @@ -15,8 +16,14 @@ define([ "dojo/dom-class" ], function(ContentPane, declare, event, registry, style, - lang, Promise, on, hash, all, xhr, query, iframe, + lang, Promise, Deferred, on, hash, all, xhr, query, iframe, domClass) { + var docURL = new URL(document.location); + var domReject = function (request) { + return ( + request.getResponseHeader("X-LedgerSMB-App-Content") !== "yes" || + (request.getResponseHeader("Content-Disposition") || "").startsWith("attachment")); + }; return declare("lsmb/MainContentPane", [ContentPane], { @@ -56,17 +63,61 @@ define([ }); }, load_form: function(url, options) { + var tgt = new URL(url, docURL); + if (tgt.origin !== docURL.origin) { + return (new Deferred()).resolve(); + } + var self = this; self.fade_main_div(); - return xhr(url, options).then( - function(doc){ + var req = new XMLHttpRequest(); + var dfd = new Deferred(function () { + req.abort(); + }); + try { + req.open(options.method || "GET", tgt); + var headers = options.headers || {}; + for (var hdr in headers) { + req.setRequestHeader(hdr, headers[hdr]); + } + if (options.data && + !(options.data instanceof FormData) && + ! headers["Content-Type"]) { + req.setRequestHeader( + "Content-Type", + "application/x-www-form-urlencoded" + ); + } + req.setRequestHeader("X-Requested-With", "XMLHttpRequest"); + req.addEventListener("load", function () { + dfd.resolve(req); + }); + req.addEventListener("error", function () { + dfd.reject(req); + }); + req.send(options.data || ""); + } catch (e) { + dfd.reject(e); + } + + return dfd.then( + function (request) { + if (domReject(request)) { + return self.show_main_div(); + } + self.hide_main_div(); - self.set_main_div(doc); + return self.set_main_div(request.response); }, - function(err){ + function (request) { + if (domReject(request)) { + return self.show_main_div(); + } + self.show_main_div(); - self.report_request_error(err); - }); + return self.report_request_error({ err: request }); + } + ); }, download_link: function(href) { // while it would have been nice for the code below diff --git a/lib/LedgerSMB/Middleware/DynamicLoadWorkflow.pm b/lib/LedgerSMB/Middleware/DynamicLoadWorkflow.pm index 94737a25d..6964798a5 100644 --- a/lib/LedgerSMB/Middleware/DynamicLoadWorkflow.pm +++ b/lib/LedgerSMB/Middleware/DynamicLoadWorkflow.pm @@ -28,6 +28,7 @@ use parent qw ( Plack::Middleware ); use List::Util qw{ none any }; use Module::Runtime qw/ use_module /; use Plack::Request; +use Plack::Util; use LedgerSMB::PSGI::Util; @@ -95,7 +96,15 @@ sub call { $env->{'lsmb.script_name'} = $script_name; $env->{'lsmb.action'} = $action; $env->{'lsmb.action_name'} = $action_name; - return $self->app->($env); + return Plack::Util::response_cb( + $self->app->($env), + sub { + if (not Plack::Util::header_exists($_[0]->[1], + 'X-LedgerSMB-App-Content')) { + Plack::Util::header_push($_[0]->[1], + 'X-LedgerSMB-App-Content', 'yes'); + } + }); } diff --git a/lib/LedgerSMB/PSGI.pm b/lib/LedgerSMB/PSGI.pm index 328e80ad3..ec8be07f1 100644 --- a/lib/LedgerSMB/PSGI.pm +++ b/lib/LedgerSMB/PSGI.pm @@ -78,7 +78,7 @@ Returns a 'PSGI app' which handles requests for the 'old-code' scripts in old/bi =cut sub old_app { - return CGI::Emulate::PSGI->handler( + my $handler = CGI::Emulate::PSGI->handler( sub { my $uri = $ENV{REQUEST_URI}; $uri =~ s/\?.*//; @@ -86,6 +86,18 @@ sub old_app { _run_old(); }); + + return sub { + return Plack::Util::response_cb( + $handler->(@_), + sub { + if (not Plack::Util::header_exists($_[0]->[1], + 'X-LedgerSMB-App-Content')) { + Plack::Util::header_push($_[0]->[1], + 'X-LedgerSMB-App-Content', 'yes'); + } + }); + } } ]]] -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

LedgerSMB 1.8.17 released
by Erik Huelsmann 28 Jul '21

28 Jul '21

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.8.17 * Align filters between UI and the database on draft transaction search (#5692) * Correctly present manual tax and invoice total on reversing invoice (#5721) * Repeatedly saving a draft invoice pops up an SQL error (#5679) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.8.17/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.8.17 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.8.17 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.8.17 These are the sha256 checksums of the uploaded files: b1eabf07226041216fe286b68d7204b2ac7925bef56140bc15b2897587e247c9 ledgersmb-1.8.17.tar.gz fcb5994b391716b8c8c51b04977717ca9d8df5edd8789a864d1afdb380a683c5 ledgersmb-1.8.17.tar.gz.asc

1 0

Re: Progress on Invoice webservice (discussion solicited)
by Erik Huelsmann 14 Jul '21

14 Jul '21

Hi David, On Mon, Jul 12, 2021 at 12:04 PM lsmbdev <lsmbdev(a)sbts.com.au> wrote: > Regarding my suggestion for 3 sets of price data to be stored against each > invoice line. > There is another reason (other than the obvious) I'm suggesting that. > It allows accurate reporting on sales "variations" > Ok. To be able to do that, I don't see more than the requirement for 2 sets: the actual data used in the invoice (which is already there now) and the numbers calculated by the system. If the numbers have not been overridden by the user, the "variation" is zero. > For example a salesperson may vary the price by applying a discount or > manually changing the price on an item. > In general thats good sales practice as long as the net sales margin from > a customer is above some target level. > Right. Or maybe other criteria that the sales has been mandated for. > Without storing all three items of data it becomes difficult, if not > impossible, to correctly report on this with enough detail to be useful for > basic oversight let alone malicious behaviour. > Ok. I can see how this would be convenient for oversight. However - assuming the business doesn't change its prices daily (but rather more quarterly or less often) - the data required to do oversight should be there when the oversight is effective: short after the actual sale. At that time, the data is all there. The pricematrix price derivation is even in the database now (see https://github.com/ledgersmb/LedgerSMB/blob/816e740f0702af2a2192dfe4832dc3e…) So, assuming sufficiently constant prices, you could retrieve the oversight data nicely. All the data needed to report e.g. an average sales price (per part) is also there. > I've run into other use cases in the past as well. > Ok. I was thinking to introduce the ability to track the applicable pricing at a given point in time, so as to be able to provide an audit trail on how invoice prices were determined. With the schema currently proposed, there will at least be an indicator that the person compiling the invoice either set their own price, or that the price was inherited from an order/quote (as contrasted by "taken from the pricing mechanism/calculated by the software"). Regards, Erik. > > Sent from my Galaxy > > > -------- Original message -------- > From: Erik Huelsmann <ehuels(a)gmail.com> > Date: 12/7/21 15:09 (GMT+08:00) > To: lsmbdev <lsmbdev(a)sbts.com.au> > Cc: devel(a)lists.ledgersmb.org, John Locke <john(a)freelock.com>, "Yves > Lavoie, GaYLi" <ylavoie(a)yveslavoie.com> > Subject: Re: Progress on Invoice webservice (discussion solicited) > > Hi David, > > Thanks for your response. We've discussed my earlier mail on the chat > channel as well; I'll summarize in response to your mail. > > On Tue, Jul 6, 2021 at 4:22 AM lsmbdev <lsmbdev(a)sbts.com.au> wrote: > >> Shouldn't the linetotal be returned within the calculated block rather >> than the user supplied block? >> Doing otherwise seems like a massive rounding nightmare. >> > > Yes, it should (and will); I was posting an unfortunate combination of > request and response structures. (since the response is just a superset of > the request, it's hard to separate the two in my mind). > > >> As for handling db side changes during the life cycle of the invoice (eg: >> price and tax changes) I'm not sure I see an easy solution. >> We currently have a problem here anyway. >> If we follow a full quote => order => invoice workflow you expect a price >> as shown on a quote to be static throughout the sequence. >> However it will most likely change if any source info changes along the >> way. >> > > That's a good point. Yes, I too expect the current implementation to apply > price-changes during that life cycle. Thanks for pointing that out: > Evaluating the solution to the original problem discussed on the chat > channel, I think that with a few minor changes we can support this workflow > the way it's expected to work. > > >> Personally, I think a specific request to update a line is required. >> To that end, I think each line should (as the first element) contain a >> boolean "recalc" element and a "lastcalc" timestamp >> As should the entire invoice. >> > > The solution we discussed on the chat channel is just as simple as > effective: John proposed we add a boolean to each invoice line which > indicates the price in that line should be excluded from pricematrix > calculations; e.g. named 'pricefreeze'. That way, the line gets excluded > from pricematrix calculations and won't be updated when the invoice gets > saved. How the UI gets to set the 'pricefreeze' boolean, is out of scope of > the current consideration. It didn't feel right to add another checkbox on > the already crowded invoice input screen. We came up with other ways to set > the value. But, as said, that's to be dealt with later. > > Applying this solution to your "full quote > invoice" workflow, I think > the expected behaviour can be had by setting the 'pricefreeze' parameter on > orders spawned from quotes and invoices spawned from orders. > > >> Regardless, there probably needs to be 3 sets of price data presented. >> - user overrides >> - system calculated >> - actual data for use >> > > The response is currently expected to hold just the price used for > calculation. I was originally expecting to send the list price or the price > matrix price too, but I found that to be confusing, because: which price do > you send when there's a price matrix price for the current vendor and > invoice line, but the user has overridden the price manually? > > >> All of the above should be permanently stored in the db. (FYI, we should >> be doing this even for non API entries as well. >> This preserves the data. Allowing better auditing and diagnostics) >> > > I was considering the option to add a time-dimension to the parts table, > allowing various parts uses to reference explicit lines in the table, with > the price data as it applied at the specific time of modification of the > quote/order/invoice. It's quite complex though, because: do you create a > full copy of the price matrix too? and what about the parts line itself > when e.g. a line in the makemodel table is changed? > > I decided that storing a full audit trail on modified parts data is > probably a good idea, but not something to be addressed while creating the > invoice API. For now, I'm really happy with John's "pricefreeze" suggestion > as it allows us to move forward on the implementation without endless > complexities. > > >> There is probably more to consider, but there's a start for discussion >> > > Regards, > > Erik. > > >> >> Regards >> David G >> >> -------- Original message -------- >> From: Erik Huelsmann <ehuels(a)gmail.com> >> Date: 6/7/21 04:56 (GMT+08:00) >> To: devel(a)lists.ledgersmb.org >> >> Hi, >> >> Over the past months, I've been working on a webservice for LedgerSMB to >> post invoices. The current status can be viewed here: >> https://github.com/ehuelsmann/LedgerSMB/blob/webservices/lib/LedgerSMB/Rout… >> >> Summarizing what I have achieved so far: >> >> * An endpoint /erp/api/v0/invoices/, which accepts POST requests >> * The "specification" of the payload can be found here: >> https://github.com/ehuelsmann/LedgerSMB/blob/webservices/lib/LedgerSMB/Rout… >> * The toplevel keys "eca", "account", "dates", "lines", "taxes", >> "currency", "description", >> "invumber", "ordnumber", "ponumber" are supported >> * The pricematrix is consulted when determining pricing >> * Customers and vendors are supported (each with their own type of >> pricematrix) >> >> The endpoint has been coded defensively, throwing an "unacceptable input" >> error on anything that's not consistent with what the database should >> expect. A lot of things are currently not supported: >> >> * Invoices will end up in "draft" state and cannot be Post-ed >> * Payments are not processed >> * Rounding (in the price matrix, but also of the line-totals) isn't in >> place >> * Complex taxes have limited support ("simple taxes only") >> * No multi-currency support yet >> * No support for "taxes included" tax extraction calculation (from the >> gross invoice amount) >> * I have no idea what happens with Cost Of Goods Sold calculations >> * No support for shipping addresses >> * No support for printing/mailing/etc. >> * All invoices are posted into the 'ar' table (oops!) >> >> That said, I have some questions with respect to what the functionality >> needs to be able to do, especially with respect to saving invoices in order >> to post them later. With respect to saving and posting invoices, I'm >> envisaging the workflow to require a number (lots) of save actions on the >> invoice in order to calculate its prices, i.e. to calculate the price >> matrix. There may be other reasons to save the invoice in the mean time. >> In the current invoice-entry process (running through "old code"), >> there's a lot of code which tries to determine if anything changed in the >> invoice based on the fields entered. If it did (or rather, if the deduction >> code thinks it did), the invoice will be recalculated either partial or in >> full. >> This code causes lots of headaches, because most of the time the user >> didn't expect their edits to trigger a full recalculation, or, the >> recalculation didn't happen the way it should e.g. due to the fact that >> prices had been overridden by the user. >> To prevent similar complexity in the webservice, I've created a structure >> where each line returns the data entered by the user (as provided on input) >> as well as calculated data. It is up to the front-end to present that data >> in a useful way to the user. Just as an example, the following structure >> could be a line in the invoice: >> >> { "part": { "number": "p1", "description": "p1 desc", "price": 1.23 }, >> "quantity": 5, >> "description": null, "price": null, "linetotal": 6.15, "discount": >> null } >> >> The above line means to say that the user didn't enter a price, >> description or discount. The part has been configured with a price of $1.23 >> for the current customer/vendor and the quantity on the line is 5 (as >> entered by the user). If the user enters a description, the description >> field in the line itself gets filled with that, e.g. "bike rental fees". >> Assuming that the user saves the above line without further input and >> continues by posting the invoice, I'm thinking that the posting action >> should copy the description and price from the part configuration to the >> invoice. >> This poses a timing challenge: what if in the mean time the part >> configuration gets changed and the price is updated to 5.23? Then the >> actual invoice posted goes from a linetotal of 6.15$ to 25.15$. Seems >> unacceptable. >> So, the other option is: create a "calculate the price matrix for this >> invoice without actually storing it" endpoint and do the "copy data from >> part" step on save instead of on posting. Here, I'm running into a problem >> too: lets assume the user wants to save the invoice only to work on it more >> tomorrow? In that case, all the prices have been filled and the price >> matrix calculation won't work anymore, because it doesn't work due to the >> "price" fields no longer being 'null'. >> >> The above problem exists not only for parts, but also for taxes; maybe >> other scenarios too. >> >> By posting this, I hope to get some good discussion on the topic (and >> hopefully some good additional ideas)! >> >> >> >> >> -- >> Bye, >> >> Erik. >> >> http://efficito.com -- Hosted accounting and ERP. >> Robust and Flexible. No vendor lock-in. >> > > > -- > Bye, > > Erik. > > http://efficito.com -- Hosted accounting and ERP. > Robust and Flexible. No vendor lock-in. > -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 1

Re: Progress on Invoice webservice (discussion solicited)
by Erik Huelsmann 12 Jul '21

12 Jul '21

Hi David, Thanks for your response. We've discussed my earlier mail on the chat channel as well; I'll summarize in response to your mail. On Tue, Jul 6, 2021 at 4:22 AM lsmbdev <lsmbdev(a)sbts.com.au> wrote: > Shouldn't the linetotal be returned within the calculated block rather > than the user supplied block? > Doing otherwise seems like a massive rounding nightmare. > Yes, it should (and will); I was posting an unfortunate combination of request and response structures. (since the response is just a superset of the request, it's hard to separate the two in my mind). > As for handling db side changes during the life cycle of the invoice (eg: > price and tax changes) I'm not sure I see an easy solution. > We currently have a problem here anyway. > If we follow a full quote => order => invoice workflow you expect a price > as shown on a quote to be static throughout the sequence. > However it will most likely change if any source info changes along the > way. > That's a good point. Yes, I too expect the current implementation to apply price-changes during that life cycle. Thanks for pointing that out: Evaluating the solution to the original problem discussed on the chat channel, I think that with a few minor changes we can support this workflow the way it's expected to work. > Personally, I think a specific request to update a line is required. > To that end, I think each line should (as the first element) contain a > boolean "recalc" element and a "lastcalc" timestamp > As should the entire invoice. > The solution we discussed on the chat channel is just as simple as effective: John proposed we add a boolean to each invoice line which indicates the price in that line should be excluded from pricematrix calculations; e.g. named 'pricefreeze'. That way, the line gets excluded from pricematrix calculations and won't be updated when the invoice gets saved. How the UI gets to set the 'pricefreeze' boolean, is out of scope of the current consideration. It didn't feel right to add another checkbox on the already crowded invoice input screen. We came up with other ways to set the value. But, as said, that's to be dealt with later. Applying this solution to your "full quote > invoice" workflow, I think the expected behaviour can be had by setting the 'pricefreeze' parameter on orders spawned from quotes and invoices spawned from orders. > Regardless, there probably needs to be 3 sets of price data presented. > - user overrides > - system calculated > - actual data for use > The response is currently expected to hold just the price used for calculation. I was originally expecting to send the list price or the price matrix price too, but I found that to be confusing, because: which price do you send when there's a price matrix price for the current vendor and invoice line, but the user has overridden the price manually? > All of the above should be permanently stored in the db. (FYI, we should > be doing this even for non API entries as well. > This preserves the data. Allowing better auditing and diagnostics) > I was considering the option to add a time-dimension to the parts table, allowing various parts uses to reference explicit lines in the table, with the price data as it applied at the specific time of modification of the quote/order/invoice. It's quite complex though, because: do you create a full copy of the price matrix too? and what about the parts line itself when e.g. a line in the makemodel table is changed? I decided that storing a full audit trail on modified parts data is probably a good idea, but not something to be addressed while creating the invoice API. For now, I'm really happy with John's "pricefreeze" suggestion as it allows us to move forward on the implementation without endless complexities. > There is probably more to consider, but there's a start for discussion > Regards, Erik. > > Regards > David G > > -------- Original message -------- > From: Erik Huelsmann <ehuels(a)gmail.com> > Date: 6/7/21 04:56 (GMT+08:00) > To: devel(a)lists.ledgersmb.org > > Hi, > > Over the past months, I've been working on a webservice for LedgerSMB to > post invoices. The current status can be viewed here: > https://github.com/ehuelsmann/LedgerSMB/blob/webservices/lib/LedgerSMB/Rout… > > Summarizing what I have achieved so far: > > * An endpoint /erp/api/v0/invoices/, which accepts POST requests > * The "specification" of the payload can be found here: > https://github.com/ehuelsmann/LedgerSMB/blob/webservices/lib/LedgerSMB/Rout… > * The toplevel keys "eca", "account", "dates", "lines", "taxes", > "currency", "description", > "invumber", "ordnumber", "ponumber" are supported > * The pricematrix is consulted when determining pricing > * Customers and vendors are supported (each with their own type of > pricematrix) > > The endpoint has been coded defensively, throwing an "unacceptable input" > error on anything that's not consistent with what the database should > expect. A lot of things are currently not supported: > > * Invoices will end up in "draft" state and cannot be Post-ed > * Payments are not processed > * Rounding (in the price matrix, but also of the line-totals) isn't in > place > * Complex taxes have limited support ("simple taxes only") > * No multi-currency support yet > * No support for "taxes included" tax extraction calculation (from the > gross invoice amount) > * I have no idea what happens with Cost Of Goods Sold calculations > * No support for shipping addresses > * No support for printing/mailing/etc. > * All invoices are posted into the 'ar' table (oops!) > > That said, I have some questions with respect to what the functionality > needs to be able to do, especially with respect to saving invoices in order > to post them later. With respect to saving and posting invoices, I'm > envisaging the workflow to require a number (lots) of save actions on the > invoice in order to calculate its prices, i.e. to calculate the price > matrix. There may be other reasons to save the invoice in the mean time. > In the current invoice-entry process (running through "old code"), there's > a lot of code which tries to determine if anything changed in the invoice > based on the fields entered. If it did (or rather, if the deduction code > thinks it did), the invoice will be recalculated either partial or in full. > This code causes lots of headaches, because most of the time the user > didn't expect their edits to trigger a full recalculation, or, the > recalculation didn't happen the way it should e.g. due to the fact that > prices had been overridden by the user. > To prevent similar complexity in the webservice, I've created a structure > where each line returns the data entered by the user (as provided on input) > as well as calculated data. It is up to the front-end to present that data > in a useful way to the user. Just as an example, the following structure > could be a line in the invoice: > > { "part": { "number": "p1", "description": "p1 desc", "price": 1.23 }, > "quantity": 5, > "description": null, "price": null, "linetotal": 6.15, "discount": > null } > > The above line means to say that the user didn't enter a price, > description or discount. The part has been configured with a price of $1.23 > for the current customer/vendor and the quantity on the line is 5 (as > entered by the user). If the user enters a description, the description > field in the line itself gets filled with that, e.g. "bike rental fees". > Assuming that the user saves the above line without further input and > continues by posting the invoice, I'm thinking that the posting action > should copy the description and price from the part configuration to the > invoice. > This poses a timing challenge: what if in the mean time the part > configuration gets changed and the price is updated to 5.23? Then the > actual invoice posted goes from a linetotal of 6.15$ to 25.15$. Seems > unacceptable. > So, the other option is: create a "calculate the price matrix for this > invoice without actually storing it" endpoint and do the "copy data from > part" step on save instead of on posting. Here, I'm running into a problem > too: lets assume the user wants to save the invoice only to work on it more > tomorrow? In that case, all the prices have been filled and the price > matrix calculation won't work anymore, because it doesn't work due to the > "price" fields no longer being 'null'. > > The above problem exists not only for parts, but also for taxes; maybe > other scenarios too. > > By posting this, I hope to get some good discussion on the topic (and > hopefully some good additional ideas)! > > > > > -- > Bye, > > Erik. > > http://efficito.com -- Hosted accounting and ERP. > Robust and Flexible. No vendor lock-in. > -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 1