Todo List
wascore
- Entropy! Perhaps it is better to value the strength of a password in a different way, say 'CorrectHorseBatteryStaple' could be better than 'Tr0ub4dor&3'. Also, why force a limited set of ASCII-characters [0-9A-Za-z] when there is so much entropy to gain by using characters in the range U+0080 - U+10FFFF? (20140912/PF)
- there is someting not right with buffering the tabledefs. If an error occurs, we get FALSE instead of an array. Mmmmm....
- add a 'funnel mode': disable all distracting links that could seduce the user to leave and leave locked records (eg. nodes)
- carefully check if we need more headers in html-head section of document, see AdminOutput().
- do we need a link rel="shortcut icon" type of header too?
- do we really need more meta-headers?
- is it really wise to add a base header? It interferes with the session cookie whenever you login at another URL than the base+'admin.php'... Comment it out for now
- we need to take care of spurious spaces in inputs (or do we?)
- since multiple tables are involved, shouldn't we use transaction/rollback/commit? Q: How well is MySQL suited for transactions? A: Mmmmm.... Which version? Which storage engine?
- should we add a paging function to the list of areas? Currently all areas are shown in a single list...
- should we make two categories: 'public' and 'private' in the list of areas? Maybe handy when there are many manu areas, but it would be inconsistend with the page manager menu which simply lists the areas in the sort order. Easy way out: the user is perfectly capable to set the sort order in such a way that the sort order already groups the public and private areas. Oh well....
- should we acknowledge the changed default to the user or is it enough to see the icon 'move'?
- should we send alerts? If so, can we use the routine to queue messages from pagemanager? A reason not to send alerts: the alerts will be sent as soon as a page is added to the new area, so why bother?
- Clean up this code, it is very hairy
- split into two separate routines, one to set the tree, another to construct the list of anchors
- 'enum' type equivalent with varchar, enum_values[] array is not used at all, only as a form of documentation
- should we allow both int and integer?
- 'enum' type equivalent with varchar, enum_values[] array is not used at all, only as a form of documentation
- should we allow both int and integer?
- perhaps extend this function to accept more than 2 strings?
- perhaps extend this function to accept more than 2 strings?
- weigh pros and cons of persistent database connections, perhaps add as config option?
- weigh pros and cons of persistent database connections, perhaps add as config option?
- perhaps change the possible values of $type to full strings rather than 'cryptic' single letter codes. Furthermore: what do we do with invalid dates, times and date/times? For now it is a stub, returning $value as-is. Oh well.
- document correct link for documentation of generic table definition 'tabledefs.php'
- document correct link for documentation of generic table definition 'tabledefs.php'
- document correct link for documentation of generic table definition 'tabledefs.php'
- find a way to deal with the enum values: where do we keep them? Or do we keep them at all?
- document correct link for documentation of generic table definition 'tabledefs.php'
- find a way to deal with the enum values: where do we keep them? Or do we keep them at all?
- perhaps add postgresql in a future version
- should we do something with locking the session record from dbsession_open() until dbsession_close()? For now, the session record is not locked in any way, so the latest call gets to keep its changes Mmmm....
- should we also record the IP-address of the user in the session record? In a way this is a case of information leak, even though it is only between authenticated users. Mmmm...
- this routine should not need to know about nodes and stuff. Mmmm... remove FK constraint?
- since multiple tables are involved, shouldn't we use transaction/rollback/commit? Q: How well is MySQL suited for transactions? A: Mmmmm.... Which version? Which storage engine?
- if we let the hotkey from the label prevail and add it to the input tag, why add a hotkey to the label too?
- we could manipulate the title attribute of input strings like "please enter a number between {MIN} and {MAX}" based on the various value properties instead of just displaying the title. oh well, for a future version, perhaps...
- we now only cater for buttons via input type="submit" without the option to visualise the accesskey. Using the button tag could solve that, but button is not defined beforde HTML 4.01. What to do?
- if we let the hotkey from the label prevail and add it to the input tag, why add a hotkey to the label too?
- should we do something with an um-empty $value? If so, waht? The browser ignores this...
- if we let the hotkey from the label prevail and add it to the input tag, why add a hotkey to the label too?
- if we let the hotkey from the label prevail and add it to the input tag, why add a hotkey to the label too?
- bailing out on non-array is a crude way of error handling: this needs to be fixed
- Q: do we really want to 'leak' a link to the main site?
- a nice filter for JOB_IMAGEBROWSER and also an alternative user interface for browsing/selecting images
- should we make the defaults in this routine configurable? (I'm not convinced they should)
- handle the related information in this dialog
- handle the related information in this dialog
- try to figure this out: when the delimiter in $name was a dot '.' $_POST contained a '_' instead. WTF? (it seems that a colon works... for now)
- retrieve this list from 'config'-table?
- should we check to see if the area is empty before showing delete icon? Or is it soon enough to refuse deletion when the user already clicked the icon? I'd say the latter. For now...
- should we display trash can icons for sections with non-empty subsections? there really is no point, because we eventually will not accept deletion of sections with grandchilderen in task_node_delete. Hmmmmm..... For now I just added the condition that access is denied when a section has grandchilderen. Need to refine this, later. Also, how about readonly nodes? Surely those cannot be deleted... should it not show in the icon?
- if this is a public area, the user can see every page, except the expired/embargo'ed ones should we take that into account too? I'd say that is way over the top. How about pages in an intranet where the user has view privilege? Complicated. KISS: only show preview to those that can edit or edit content.
- should we take path_info into account here too???? how about /area/aaa/node/nnn instead of /aaa/nnn???
- should we return an error for an invalid specific language?
- Perhaps this class should be merged with the UserManager class because there is a lot of overlap. Mmmmm.... maybe in a future refactoring operation.
- since multiple tables are involved, shouldn't we use transaction/rollback/commit? Q: How well is MySQL suited for transactions? A: Mmmmm.... Which version? Which storage engine?
- maybe we should find a more elegant way to check a field for uniqueness
- should we delete the datadirectory if something goes wrong?
- FixMe: we need to take the parent nodes into account too!
- FixMe: we need to take the parent nodes into account too!
- should we merge this with html_a() and/or rename this routine to html_href()?
- we should refactor and combine install_theme() and install_module()
- we should refactor and combine install_theme() and install_module()
- this function also 'repairs' circular references. This should move to a separate tree-repair function but for the time being it is "convenient" to have automatic repairs...
- this function also 'repairs' circular references. This should move to a separate tree-repair function but for the time being it is "convenient" to have automatic repairs...
- this routine is a little bit too long, it should be split into smaller chunks
- fix permissions for backup tool! perhaps another bit?
- should we add a paging function to the (perhaps looooong) list of languages?
- do we need a 'force lock' option to forcefully take over spurious locks? Maybe guru can override?
- perhaps we can save 1 trip to the database by checking for something like UPDATE SET locked_by = $session_id WHERE (id = $id) AND ((locked_by IS NULL) OR (locked_by = $session_id)) but I don't know how many affected rows that would yield if we already had the lock and effectively nothing changes in the record. (Perhaps always update atime to force 1 affected row?)
- should we make this configurable and maybe log directly to syslog (with automatic logrotate) or do we want to keep this 'self-contained' (the webmaster can read the table, but not the machine's syslog)?
- should we normalize the remote_addr everywhere? We now rely on the remote_addr being equal to some stored value (in the database) but with an IPv6 address there are several possibilities to have different representations of the same address (e.g. '::dead:beef' is equivalent to ::0:dead:beef' or even '::DeAd:BeeF' or '0000:0000:0000:0000:0000:0000:DEAD:BEEF'. This problem also exists with IPv4: '127.0.0.1' is equivalent to '127.000.000.001'. *sigh*
- should we suppress the username in the laissez-passer routine? We _do_ leak the the username in an insecure email message. This does require making the laissez-passer code unique in the database (currently only username+code has to be unique and that's easy because the username itself is unique).
- Should we first change $remote_addr to canonical form for good comparison? (20140912/PF)
- Maybe we could insert the parameters from $add into $path_info. OTOH: adding the existing way always works. If it aint broken... (2014-10-09/PF)
- should we cater for a special 'print' button + support for a special style sheet for media="print"?
- should we act differently based on how we are called (cli or web), eg send more queued alerts?
- should we build extra access protection via passwords and/or IP-addresses?
- cleanup login/logout-code
- add the performance results in a HTML-comment if not CFG->debug, in sight otherwise
- should we pass the area_id at all? What happens when a node is moved to another area without informing the module? Questions, questions, questions...
- should we pass the area_id at all? What happens when a node is moved to another area without informing the module? Questions, questions, questions...
- should we sanitise the modulename here? It is not user input, but it comes from the modules table in the database. However, if a module name would contain sequences of "../" we might be in trouble
- should we sanitise the modulename here? It is not user input, but it comes from the modules table in the database. However, if a module name would contain sequences of "../" we might be in trouble
- Now if the sha1-hash was compressed into 5 or 6 bits/char instead of hexadecimal digits this routine would fail miserably, so don't do that.
- maybe we should get rid of this $PERFORMANCE object, because it doesn't do that much anyway
- should we change the code to accomodate the canonical newline CRLF in the input?
- maybe optimise this routine to let pure ASCII-words through unencoded (in a later version)
- how about UTF-8 hostnames? Mmmm...
- should we check for overlong UTF-8 encodings: C0 AF C0 AE C0 AE C0 AF equates to /../ or is that dealt with already by filtering on letters/digits and embedded dots/dashes/underscores?
- fix the crude error check on dialogdef === FALSE here
- there is something wrong with embargo: should we check starting at parent or at node? this is not clear: it depends on basic/advanced and whether the embargo field changed. mmmm... safe choice: start at node_id for the time being
- this routine could be improved by refactoring it; it is too long!
- should we bring the Capi-Tali-Sation of $name in line with the default capitalisation in the list above?
- should we take the locale into account formatting numbers (thousands separator)?
- This routine is way too long, it should be split up into smaller subroutines
- it is a pity I cannot reference $this->sort from within the 6 cmp-functions...
- should we allow for fancy selection mechanisms on the logfile or is that over the top?
- should we display trash can icons for sections with non-empty subsections in treeview? there really is no point, because we eventually will not accept deletion of sections with grandchilderen. Hmmmmm.....
- the check on permissions can be improved (is PERMISSION_XXXX_EDIT_NODE enough?)
- there is an issue with redirecting to another site: officially the url should be fully qualified (ie. $CFG->www). I use the shorthand, possibly without scheme and hostname ($CFG->www_short). This might pose a problem with picky browsers. See calculate_uri_shortcuts for more information.
- about 'sort_order': do we insert nodes at the end or the beginning of a parent section?
- how do we alert users that an embargo date has come around? Do we schedule alerts via cron?
- should we massage the directory and file names of the included theme?
- what if the theme is not found? Currently no alternative is loaded but FALSE is returned.
- Should we enforce valid UTF8 in $reference and $ip_addr? We might have substr() trouble...
- This routine should be called from cron.php every once in a while
- repairing a node doesn't really belong here, in this routine. we really should have a separate 'database repair tool' for this purpose. someday we'll fix this....
- what if we need the trees of two different areas? should the static var here be an array, keyed by area_id?
- how about making all nodes under embargo visible when previewing a page or at least the path from the node to display?
- Should we take care of the race condition in this routine? Should we already create an empty file or is that clutter?
- maybe extend this routine to actually store more statistics information in a separate table
- Perhaps this class should be merged with the GroupManager class because there is a lot of overlap. Mmmmm.... maybe in a future refactoring operation.
- since multiple tables are involved, shouldn't we use transaction/rollback/commit? Q: How well is MySQL suited for transactions? A: Mmmmm.... Which version? Which storage engine?
- maybe we should find a more elegant way to check a field for uniqueness
- shouldn't we end with the edit-user dialog rather than the users overview? that might make more sense...
- the check on '/../' is inconclusive if the $path is encoded in UTF-8: the overlong sequence 2F C0 AE 2E 2F eventually yields 2F 2E 2E 2F or '/../'. Reference: RFC3629 section 10.
- maybe use MIME for sending alert if not 7bit message?
- This routine is quite *nix-centric. I'm not sure how this would work other server platforms. Should we do something about that?
- should we handle the option of a better compression level (eg. level 9) in gzcompress()? we could check to see if CMF equals 0x78 and FLG is either 0x01, 0x5E, 0x9C or 0xDA the latter 4 values might have an effect on general purpose bit flag bits 2 and 3. for now we'll just keep it simple, but there might be a little something to improve here.
- should we handle the possibility of an additional 4 bytes for DICTID (RFC1950, reference [2])?
wasmod_aggregator
- perhaps we should check more thoroughly for node existence but that implies also checking for user access etc. etc. We postpone that to later when the visitor's credentials will be checked against the list of nodes. So: a syntax check only. Sort of.
- what to do with htmlpages containing h1's and h2's? Get rid of those? Mmmm....
wastheme_axis
- maybe make this a little less quick and dirty?
wasmod_confab
- We may have to enforce usernames cannot end in an asterisk in Account Manager.
wasmod_crew
- should we take status=0 into account too (individual entry to the workshop)? it looks like a lot of effort for a low yield
- FixMe: we need to take parent node permissions into account as soon as we can assign crew permissions to sections. We now specificly look at permissions in table acls_modules_nodes OR at global (guru) permissions for modules in table acls. (June 2013).
- FixMe: we should rename SaveEdit and Save to Save and Done (May 2014)
- FixMe: we should somehow add a csrftoken into the mix (May 2014)
wasinstall
- add more tests, e.g. for gd, safe_mode, memory limit, etc.
- get rid of the $wizard kludge!
- should we also add groups_capacities, acls, users_groups_capacities to $config or are users and groups enough?
- should we append an underscore to the userpaths to make sure we don't clash with the first user account?
- should we check the program version versus the stored program version here?
- there is something wrong with the default for $cms_www; FIXME (commented out for now)
- should we promote language and high_visibility to function parameters instead of using $_SESSION directly?
- how prevent third party-access to install.php after initial install? .htaccess? !exists(../config.php)?
- we should make sure that autosession is disabled in php.ini, otherwise was won't work
- we should make sure that register globals is off
- we should make sure that we can actually set cookies (necessary when logging in).
- should we save the config.php to the datadir if the main dir fails? Mmmm.... security implications?
- this routine badly needs refactoring
- also take safe_mode into account? Should that be a requirement for succesfull installation?
- can we suppress even more fields here in case of a Standard installation?
- more tests to perform here: safe mode, memory limit, processing time limit, register globals
- automatically create appropriate sequence name for serial fields??? or add seqdefs too?
- should we make the filemode (hardcoded at 0400) configurable/customisable?
wasmod_htmlpage
- change this stub into a real cron function.
- should we add a title here?
- get rid of 'version' field and related cruft (or do something useful with it). 2014-05-05/PF
wasmod_mailpage
- extra validation of set_mailreplyto and set_subject?
- make body of mail configuratble?
- more available parameters in subject_line?
- should we have an OK button at all???
wasmod_mypage
- should we remove username and datadir altogether?
wasmod_newsletter
- There are various stubs that need to be fixed.
- what to do with equal email addresses: can those simply be added or must they be unique?
- we may be doing double work by searching/replacing the same url()'s again and again
- extra validation of set_mailreplyto and set_subject?
- make body of mail configuratble?
- more available parameters in subject_line?
- should we have an OK button at all???
wastheme_rosalina
- should we take path_info into account here too???? how about /area/aaa/node/nnn instead of /aaa/nnn???
- maybe make this a little less quick and dirty?
wastheme_schoolyard
- maybe make this a little less quick and dirty?
wasmod_search
- better parse of keywords taking quotes into account too.
- is there a chance that our static cache $q fails if somehow a different $qwords is used on subsequent calls? Mmmmm...
- what to do with overlapping qwords, eg. "foo" and "foobar"? result depends on search/replace execution order: either "foobar" or "<b>foobar</b>
- should we use the token routines here too?
wasmod_snapshots
- check for information leaks (private path) here?
- check permissions (ACL) to prevent leaking a private area path to anonymous visitors?
- check permissions (ACL) to prevent leaking a private area path to anonymous visitors?
- should the user / group really be active here? If not, the images will fail in file.php but that may leak information about inactive users. Hmmm...
- we should use a different error message as soon as it is available in was.php, eg. 'validate_bad_directory' (much like 'validate_bad_filename').
- we might want to jazz up this dialog by adding some sort of 'directory browser' for the snapshots_path field using a pop-up window. Mmmmm.... future refinements...
Documentation generated on Tue, 28 Jun 2016 19:12:53 +0200 by phpDocumentor 1.4.0