luci / News: Recent posts

- document qmeta

- fix url provided is not valid etc...

this has been updated

- debug is available for luci.cgi, should we have a global debug that can

be used for the libraries? should all of luci have debugging?

took this out of the TBA list seeing as the functionality has been added

- _denylist/_allowlist

see config for rules/conventions

note: you can use the allowlist/denylist settings together to allow

most files, but not all from a specific domain

- added _denylist feature

- allowed_domains renamed _allowlist

- under apache 2, we noticed luci having difficulties with path_info

when the request for luci is already a path_info request. the solution

was to simply rebuild the original url, then pull path_info from there

my $path_info = ($config->{system}->{apache_2}=~/true/i)

? URI::URL->new($ENV{REQUEST_URI}, $ENV{SERVER_URL})->abs->as_string

CGI::url(-path_info => 1);
- added default value to $sep variable

Some major bug fixes and added functionality:

- wait for john's final version of his MS Environment (2003) doc
update the website doc when it arrives
- making use of config feature to allow deeper debugging
ie. in the modules
- there is an issue with multi-checkboxes in post request
multi-checkboxes were posting null delimited and are now cleaned up and
sent as distinct entries
- ok we're done with findbin and mod @INC directly
use vars qw($path $sep);
BEGIN { # see changelog
$0=~s/^(.*)(\/|\\)// and $path=$1 or $path='.';
$sep = $2;
unshift @INC, $path.$sep."lib";
}
this allows a little more flexibility, passes taint and works on MS
- added a config setting for apache 2
note: default apache 2 install does not recognize path_info as a
separate entity, and returns the entire url regardless
- update MS 2000 docs
done.
- add MS 2003 docs - will require testing
done.
- perlis.dll
john's document to provide instruction's based on perlis.dll
- what about one instance that calls another that calls back, etc...
if two instances simply reference each other via path_info
this is clean.
if path_info =~ app_root_url, luci will spawn (self recursing)
this is fixed. we fail over to default_target
if two instances reference each other via default_target
there is a possibility of infinite loop here
this is fixed.
1. since this is recursive, we test for app_root_url in path_info
2. on occurrence, we intend to swap for default_target
3. if default_target == app_root_url... fatal error
- test MS 2003 https
- update docs wrt LUCI_CONF and FindBin
- update cvs link - check all links
clean up links to yourdomain. they should not href
- add john to contrib
- add john's doc to the website
- use lib (($FindBin::Bin.'/lib')=~/^(.*)$/);
solution ported from FindBin::libs (find_libs subroutine)
see source: http://search.cpan.org/src/LEMBARK/FindBin-libs-1.25
/lib/FindBin/libs.pm
as per doc: http://www.gunther.web66.com/FAQS/taintmode.html#require
when running taint mode (-T), '.' is removed from @INC
we need '.' in order to reference our lib which is at './lib'
we could set lib manually
ex: use lib './lib'
unfortunately, this is not portable. Under the MS environment (2003),
this simply will not work, and we would like to avoid having users edit
the executables directly. the solution is to use FindBin, which will
produce cwd. Unfortunately, FindBin will not pass the taint check when
used in this context because $FindBin::Bin is tainted. the solution is to
untaint
- again have corrected a bug found in the attempt to pull a proper path_info
as opposed to failing, we now correct the error by setting path_info
manually if it is not provided. this fix also rectifies the error found
under MS where an incorrect value is supplied as path_info when no path
info is supplied. if app_root_url is not set correctly in the config,
the user will notice that links will not work properly. after turning on
debug, it may be noted that app_root_url under config does not match the
base url that can be viewed at the top of a browser window.
- cleaned up debug settings
1 dumps vars/env/config
2 dumps object data also
- converted index.cgi redirect to use CGI::redirect
simple location: print would not work
- now making use of FindBin for locating luci.conf.cgi
this was required as a MS fix
- added feature that allows toggle of heading level display
see conf
- modified the CBC specification in PageFetcher.pm. someone ran into
problems where the iv was required even though prepend_iv was set
false. anyway, these options were removed, and having header set
as 'salt' should allow CBC to generate the cipher key and the iv
from the passphrase (in our case, the cryptkey)
- added feature <span class="luciignore"> ignore this </span>
added documentation for this feature
- update sourceforge admin
added screenshots
removed forum and patch tracker
updated all tracker items to correspond with shawnmcginn@sourceforge.net
cleaned up current tracker items
- look at TBA
some of this was completed.
- should output follow the xhtml standard?
added use of module HTML::Entities for proper URL encoding
most other errors cannot easily be corrected by luci. for example, it
is a requirement that the id attribute value begin with a character and
not a digit. if it is the case that the page you are requesting does
not follow the proper convention, it will continue to fail the xhtml
standard as luci does not attempt to correct a misspelling of the id value.
also found a spelling error in the templates wrt </tbody> that was causing
an xhtml error with open tag.
note: luci does a pretty good job at cleaning up the html, in turn possibly
making a site 'more' xhtml compliant
- add DEBUGging feature (for dev)
would require levels
put DEBUG in conf (use Data::Dumper)
to date, debugging has been ad-hoc
this was done long ago. there is also a TBA on debug in modules
- documentation could use a review
this is done. docs look good
- look at possible ip forwarding
the idea here is that luci would represent herself with the ip of the
client, as opposed to the ip of her host.
we spent some time researching the possibility of forwarding the user ip
through luci, but we realize this will definitely introduce many more
challenges, and does not appear possible. for one, we believe ip spoofing
(which is somewhat indirectly the requirement here) may be considered
illegal, although this may be somewhat dependent on the context. on
another note, even if we manage to get it working, it should be noted that
ip communication is a two way street. ie. responses are returned to the
requesting ip, and if luci is to represent herself with the client ip, she
will therefore not receive the response, as it will be returned to the
client
- we had a request wrt cookie proxying. some substantial discussion
came from this, and our decision was to avoid implementing this feature
for several reasons. some info follows:
- the request:
From the LUCI documentation, it says that LUCI "stores all cookies that
the user comes across in one single cookie." Does this mean that users
that create cookies during text-only will not be able to use those
cookies in graphical view? If so, is there a workaround?
- our response:
Even though it 'may' be possible to have luci pass a cookie from
somesite.com to your browser, adding this functionality would appear
quite confusing to a client, seeing as luci cannot do the reverse;
ie. provide cookies that you have set in your browser via graphical
surfing to somesite.com. The other issue we would have to take into
consideration if we were to consider adding this feature is that we
are really unsure as to whether or not luci would be able to set a
cookie in the client browser that belongs to somesite.com and not
mysite.com. Please refer to section 4.3.2 Rejecting Cookies
(rfc2109) as per W3C: http://www.w3.org/Protocols/rfc2109/rfc2109
"a user agent rejects a cookie if
...
* The value for the request-host does not domain-match the Domain
attribute.
...."
So, in other words, a cookie with domain "somesite.com" passed to
the browser via luci hosted on "mysite.com" will be rejected.... read more

small bug fix. error on base target causing broken links

This release primarily focused on providing better functionality under IIS. The following was added to the changelog:

- include Kyle's documenation
done. Kyle's docs have been merged
- add DEBUG
done. very broad debugging has been implemented and
can be configured from luci.conf
- https test bug
when testing ssl in luci.cgi, we now check app_root_url as
opposed to testing the SERVER_URL environment variable
in an attempt to reduce environment dependencies.
- add Scott to Acknowledgements
done.
- thanks to unbsj its
done.
- add platform specific section
done.
- I tried to get luci under MS Environment to not require user
modification of the 'use lib' and LUCI_CONF constant, but
cannot seem to get around the Cwd/FindBin taint problems.
instructions for MS users will be added
- 'use lib' and LUCI_CONF ref now use single quotes.
double quotes were causing issues in the MS environment
- pod all files
done long ago. we need to complete the documentation.
- provide logo
done long ago - removed from tba.
- removed the $ENV{SERVER_URL} dependency, and now
check SSL against $config->{app_root_url};
- need to upgrade the pod in luci.cgi to reflect the new
Twofish_PP package requirement and remove Shark
done.
- switched to the Twofish_PP algorithm which seems to be
available to both UNIX and ActivePerl (PageFetcher.pm
upgrade) Shark was not available from the ActivePerl
Package Manager at the time of this writing. Although it
could probably be compiled for use under ActivePerl, it was
decided we would use the one that is immediately available
to the package manager.
- removed the use of $ENV{PATH_INFO}: now using CGI::url
and pulling path_info manually. this seems to have fixed
the PATH_INFO environment variable problem in the MS
Environment, and continues to work properly under UNIX.
- css the pod
decided against this. we like pod
- MS Environment: Luci seems to be able to parse herself.
Makes a mess.
fixed. In luci.cgi, clean url before self parse test
- MS Environment trims double slashes in path_info
fix added in luci.cgi