[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Suggested centralization of Login code
- Subject: Suggested centralization of Login code
- From: David G <..hidden..>
- Date: Tue, 30 May 2017 13:37:31 +0800
Currently we have to functionally equivalent, but separately coded Login
One is used when visiting login.pl, the other setup.pl
The purpose, and intended functionality of both of these screens is
identical, the only functional differences are
- Specific text displayed
- Number of buttons, their displayed text, and submit targets
Currently there is a fair amount of unwanted divergence in underlying
behavior due to the completely independent code implementations.
Can People please comment on the below proposal, possibly first
discussing in #ledgersmb (
https://riot.im/app/#/room/#ledgersmb:matrix.org ) and then following up
with comments to the list.
We are proposing that Yves and I fix this by
- Factor out All relevant perl code into a single module LedgerSMB::Login
- Extend the Login html template (and associated js etc) to generate the
correct variations of the login page SERVER SIDE
NOTE: it's important that we generate the html and JS variations
server side for security reasons. In many cases the setup.pl endpoint is
deliberately hidden from access. eg: a web facing installation would
normally only allow access to setup.pl from an internal, trusted network
The following is a list of points that we should consider as design
guidelines for LedgerSMB::Login
- The Login html should (as presented to the client) be a static page
that is browser cacheable
- Basic Form validation should be done in JS before submission
- Human readable error messages should be returned FOR ALL ERRORS, even
ones we don't handle specifically.
- At NO point should the user see a raw server generated error
- At NO point should the user see a silent failure (ie: the user should
ALWAYS get feedback)
- A header div should be displayed that will show a sys admin
configurable banner, that may include some variables such as
- LedgerSMB version
- Access URL
- Help URL
- LedgerSMB Website URL
- LatestVersion in series (1.5.x)
The header Div should also have provision to include an admin provided
It's up for discussion if we want to allow inclusion of html, or
require plain text in the admin provided banner.
The resulting Login page should
- make use of a tooltip div, providing information on most elements.
- Have a general look similar to, if not the same as, our existing Login.pl
- Be screen reader / accessibility friendly
- Be mobile friendly (or provide a mobile variant that can be served up
based on UA string)
NOTE: this may require changes to our PSGI handling so we can use a
different set of UI directories for a mobile variant, and fall back to
the Desktop version if a mobile version is not available
- If dojo is not available, (perhaps it's missing from the installation,
or JS is disabled on the client) a simple full viewport div should be
displayed OVER THE TOP of everything except the banner div, stating why
the Login screen can't be displayed.
- Once dojo has been confirmed available, but is being loaded, a
progress spinner should be displayed, and the page content hidden (the
progress div should be opaque).
- The spinner div should NOT be removed until all redrawing of the page
content is complete.
- Username, and Company entry boxes should be dropdown lists with manual
entry as an option.
- Values for the dropdown lists should be provided by (for now) a
ledgersmb.conf entry, in the future we will look to extend that to make
it auto populated
- There must be both a white list (previous point) and a blacklist
(regex) for both username and company dropdowns
- There must be a boolean switch to disable each of the dropdown lists,
forcing them to be manual entry only
- There may be a boolean switch to disable manual entry on each of the
dropdown lists (This may be useful where you have multiple companies
hosted in the same DB cluster, and run multiple LedgerSMB instances
where only some companies should be accessed from each instance. Here an
instance or company may simply refer to a different version of
LedgerSMB. eg: 1.4 vs 1.5)
- There must be provision to test usernames against two blacklist files
before attempting to connect to the DB with them.
- the first file is a project provided file containing "bad" usernames
such as "template0", "postgres", "root", and any others that could cause
- the second is a sysadmin provided file that can be locally created
to extend that blacklist
- Passwords should also be tested against a project provided blacklist
file, sysadmin provided blacklist file, and possibly a ledgersmb.conf
configured blacklist regex before they are submitted to the DB for
establishing a connection.
- The code that does these checks (for the password, company, and
username) should be factored out into a module (something like
LedgerSMB::SecurityValidations) which should be written to allow re-use
during user and company creation
- The perl module should handle an expiring password by directly
presenting the user with a password change dojo widget (in it's own page).
- the password change widget should (up until 1 working day before the
expiry, where a working day is Monday through Friday)
- show a "change" button and a "skip" button.
- On the last working day, the skip button should be either disabled
- validate the password against the 2 password blacklist files, and
the blacklist regex
- there should also be a sysadmin configurable (ledgersmb.conf) set
of rules and/or a regex describing what a VALID password looks like.
We may be able to leverage an existing password validation library
for this, but careful review of it's code should be done. Rolling our
own may turn out to be easier :-)
- The existing password change capabilities in both setup.pl and
login.pl should be moved to the new password change widget once it's
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Ledger-smb-devel mailing list