This patch just comments out httponly, not a good idea in my opinion
https://bitbucket.org/starius/thechess/src/d0b10ac091075be426b5051941c821a5acd6b413/wt-patch/no-http-only-cookies.diff?at=default
This patch adds support for httpOnly -> bool httpOnly=true, defaulting
to true
https://github.com/chan-jesus/vidanueva/blob/master/witty.patch
Patches are fine for development, but I am writing a CMS, and having to
require patches is not a good option.
I am looking for alternative options to communicating with iframes, but
I have not found any.
In my opinion the httponly option should not be forced on everyone,
there are situations where a cookie does not require any security.
for example:
I have an iframe that I want to have the same css theme as the parent
page,
some will argue that an attack can be made on any cookie value,
but I argue that its up to the developer to check for legal values in
that cookie before using its value,
the value is simple the name of the folder,
so its easy to verify that it is not code by running a function that
cleans the string first,
then checking its value for validity, by setting a list of legal values
in an httponly cookie.
so I have a theme called "blue", I store it in an normal cookie,
then I store a list of all legal values in an httponly cookie:
red,white,blue
a simple find function will verify it, and I do not see how this will
compromise the library's security.
Forcing security in a library like this is a good idea, but in this
case,
its over kill and by giving no other options to communicate with
javascript from an iframe,
will force me to abandon the iframe idea and have to write out those
pages,
which is slower and causes more overhead on CPU time,
iframes are fast and easy for content management,
if I am missing an alternative in this case,
please let me know, but at this point I think this patch should be
applied to an upcoming release,
I am sure you have already discussed this issue, but I can not find any
discussion on it,
so I am bring it up to find out what the issues are.
By allowing the developers to use normal cookies pushes the security
risk to the developers,
which is acceptable in cases where the restriction of such security
measures have no alternate secure workarounds.
On a side note, a lot of people said that a CMS is not a good idea with
this library,
but I am making good progress, I have a working CMS that has a few
features,
it allows the app to manage multiple domains, stores them in their own
database (supports multiple databases).
My biggest problem is that I am doing things that I can not find
documentation for,
so its been a learning curve that has taken a long time,
due to health issues, its taken even longer,
but I have not given up, and one day this CMS will be ready for general
use.
You can see my progress here:
https://github.com/WittyWizard/install
I do not know the best practices, so if you see anything that can be
improved, let me know.
This CMS is not like any out there, I am trying to do things the Witty
way,
opting to use templates and folder layouts that correlate to menu items,
its not based on back end fill in the blanks type of CMS most people are
use to,
I will add those features to it, but it will not rely on them,
instead its based on xml files, which I write to the database,
and its based on using the httpd and having web server removed for
security reasons.
I have a lot of work left, but I want a CMS all of you can be proud of,
this is a great library, its been a lot of fun learning it,
and I plan to start a video series explaining all the steps I took to
make this CMS,
but I have come to an cross roads on how to get passed this problem,
since my original design was based on using iframes,
so existing websites could be easily converted to use this CMS,
the idea is that you can just point to html pages to display them,
and the theme is the only dynamic part of that iframe,
but I also want to add support for call backs from those pages,
and to do this in a secure way is not easy, and this cookie deal is a
deal breaker,
unless I can find another way to do this,
and using contentDocument is not all that secure either, in fact its a
nightmare I wish to avoid,
because Security is my main goal with this CMS,
sorry about the long text, its the only way I know how to communicate
ideas like this.
Thanks
On Fri, 2014-05-23 at 09:56 +0400, Nagaev Boris wrote:
> Hello!
>
> AFAIK this can be changed by Wt patching only.
> https://bitbucket.org/starius/thechess/src/d0b10ac091075be426b5051941c821a5acd6b413/wt-patch/no-http-only-cookies.diff?at=default
>
> --
> Best regards,
> Boris Nagaev
>
>
> On Fri, May 23, 2014 at 4:51 AM, Jeffrey Scott Flesher Gmail
> <jeffrey.scott.fles...@gmail.com> wrote:
> > Is there a way to set httpOnly Cookies off?
> > I need to access them from Javascript.
> > I saw this patch, but its from 2011
> > https://github.com/chan-jesus/vidanueva/blob/master/witty.patch
> >
> > I understand wanting httpOnly, but if you need compatibility with
> > javascript, I see no other way to do it, unless you know of another way to
> > communicate with an iframe.
> > The problem I see using contentDocument, is that I have no way of knowing if
> > the iframe is loaded.
> >
> > Thanks.
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
