Martin Stjernholm wrote:
>"Stephen R. van den Berg" <<srb[at]cuci.nl>> wrote:
>I actually thought the reverse was the problem, i.e. that it is
>possible to access protected data through the _internal tree if one
>knows the url. So maybe someone has fixed that, then.
>What you advocate is a weaker form of security: Sure, an adversary
>_shouldn't_ know those urls, but if (s)he somehow does, it allows
>retrieval of more information that should be protected.
If Roxen one-way hashed the username/password into the generated URL,
the adversary cannot know the url (unless he knows the password).
(I'm not sure that it does, currently, though).
>We usually solve those repeated login requests by redirecting to /,
>prompt for the login there, and then redirecting back to the original
>page (which is stored as a variable during the login procedure). That
>takes care of all the issues with too-specific authorized trees. Even
True, but it trashes client-side caching, since it causes the whole site to
be visited with authorisation.
>though a really correct solution would be to introduce a system where
>more local _internal trees can be used, our experience shows that this
That would be slightly more CPU intensive in Roxen, because it'd have to
check for the _internal tree everywhere.
I'll look into this once more (also because my fix is not conclusive, it
seems), and come up with a better researched and worded fix/patch, we'll
how well that can be digested.
>>>> commit cd3cd82a2af0d19ddb060a561d296e8ca6f308cb
>>>> Take the local tree out of the repository proper
>> How about storing that local tree on a different directory in the source
>> management tree, and in the install script, simply copy it into the proper
>> spot? The problem is that there are ../local paths in quite a lot of places,
>> which makes a live sourcetree a liability, because the local tree should
>> not be managed by git in this case.
>Sounds like the remedy is worse than the pain. Can't you just use more
>specific .gitignore's instead? The old .cvsignore files has worked
>fairly ok, afterall.
Well, I tried, but the problems are:
a. In several spots in Roxen there are sometimes hardcoded, sometimes
configurable, references to ../local.
b. What I do/want/did is put a symlink in the tree which points to the
real local.
c. During checkout operations in git, this symlink is consistently being
replaced by a directory and populated with the files from the repository.
d. Even if I'd move the real local directory into the source tree (which I
want to avoid, since I have multiple Roxen trees lying around, which all
share the same local tree), there is the problem that during a checkout -f
git wipes out all other files which are not inside the repository.
So, the solution is either to move local to another subdir in the repository
and then put it in place upon installation, or we fix (a), and make sure
that there is (preferably one) a place where the local path can be configured.
>>>> commit 26ca63251a023c65a6468c8d9f1c52077caddc48
>>>> Alternatives don't always contain an array
>>>Have you gotten a real error there? The plan is that the mapping
>>>contains only arrays when a timeout is set, and otherwise it shouldn't
>>>get into that loop.
>> Yes, got real errors there. /.../
>It could perhaps happen if the timeout comes and goes between
>invocations to the same cache tag. That's not advisable - the code
>probably assumes in more than one place that the timeout is constant.
Hmmm...
in my CMS, once I find that a certain object has changed, I force all
upstream caches which contain (part of) this object to flush and recache.
That might be the cause then.
>> Not quite.
>> Picture this:
>> <eval>
>> <maketag name=emit type=container>
>> <attrib name=host>&var.db;</attrib>
>> <attrib name=source>sql</attrib>
>> <attrib name=query>
>> SELECT abc
>> FROM def
>> WHERE xyz='&form.&var._fieldid;:mysql-rxml;'
>> </attrib>
>> ...
>> </maketag>
>> </eval>
>Uh-oh, double parsing and entities inside entities.. What about this
>instead?
> <set variable="var.findval" from="form.&var._fieldid;"/>
> <emit host="&var.db;" source="sql"
> query="SELECT abc FROM def WHERE xyz='&var.findval:mysql;'">
> ...
> </emit>
>That'd also be safe from sql injection via var._fieldid (in case that
>one can be controlled by the client).
Well, two things:
- The var._fieldid is not controlled by the client.
- This emit *has* to be constructed using <maketag>, there is too much
conditional code (it's a huge template processor).
I had a third case, which was that it potentially handled large binary blobs,
but I see that I've already rewritten that to use native sql bindings.
So I'll fold here and create a double assignment in my code to get quoting
right.
--
Sincerely,
Stephen R. van den Berg.
Every successful person has had failures but repeated failure is no
guarantee of eventual success.
|