2012/2/25 Jakub Jankiewicz
> If you want to use your solution in code and we should not use Because this code:
>
>
>
>
no in my proposal you still can use the above code it's valid, I didn't say
we should not use
> is support by php, and user may want to use it, probably lots of the
> use
If you want to use your solution in code and we should not use
is support by php, and user may want to use it, probably lots of the
use it.
or code like
lots of html here
and this at the end of the very long script.
php support that and this is normal php code, If we want to use
no I meant we should not use (php( we should instead use the normal http://bassel.ws
Skype: i.know.sy | Global: +1-323-545-3855
On Fri, Feb 24, 2012 at 5:00 PM, Roger Martín wrote:
> ok.
>
> here the code:
> -
> /** the test **/
> t= "(php(echo 'hello world, tod
ok.
here the code:
-
/** the test **/
t= "(php(echo 'hello world, today is ',date('Y/m/d');)php)";
$r= php_parse_aiki($t);
echo "---\n $r \n-";
/** the parse for old aiki engine **/
function php_parse_aiki($widget){
ret
what is the risk if we only allow $i ';
}
?>
and not like ( I don't understand why something could look this
complicated):
now one thing if we want to delete the echo command, since we are inside a
widget, we can either use the php parser or just write some simple parser
that will figure ou
ok.
Implementing the (php( is possible without a php parse: replace all
outside (foo with echo "foo-with-slashes" and run a php eval. We
can add it (disabled by default (1 ) and this new markip can co-exists (2)
with other not-only-for-php-programmer markup.
(1) config option can be "cinic on
this (eval( )eval) will bit of confusing. If we want to add php it
should be . If we will have (eval( we will need to have
also ((field)) and [username] and (eval( don't tell users that this is
php. If we want learning curve to be small we need to have the same
thing as normal php file, so this:
Hi Jakubs!
Your right A pure-php engine only needs one parser (eval(...)eval) to work.
It's dangerous, but can represent a advantage: the learning curve for php
programmer is shorter. For the rest, learn php!!
PD: moustache is genial...i'm thinking to make a markup to support it!!
__
Hi folks!!
Thanks bassel for this link!.
In few words: we have micro-parser ( because we don't need a exhaustive
parse proccess ). This project is too complex for us.
___
Mailing list: https://launchpad.net/~aikiframework-devel
Post to : aikiframew
I think that eval is dangerous only if user use it to eval input taken
form user, and when it can be exploit to execute arbitrary code.
I don't see the difference between eval and php parser the user code
will be the same, the only thing that will change is our implementation
in Aiki.
On Thu, 23
Even will be not so simple to do, the same as php parser because php
code can be slit onto separated
(I don't know if that parser handle php tags)
and you can't just eval it, you need to construct the code that you
will eval or the only way to actually evaluate that code as it is, is
to inc
I agree with your assessment Jakub. I think simplifying widgets and
improving forms more important.
Thanks to rg1024, we moving in a great direction with the extracted
engines and parsers, and the updater! Great!
Jon
On Thu, Feb 23, 2012 at 5:58 PM, Jakub Jankiewicz wrote:
> Yes, I found it too
Yes, I found it too. But if we will gonna put php in aiki then we
should forget about and . this can be
another engine (thanks to Roger), so users can switch to php if they
want.
Aiki should be ship with few engines and admin panel should allow users
to select which they want, I thing that we wi
sure, try to hook it in with rg1024's new parser system so we could
test it out, why not.
Jon
On Thu, Feb 23, 2012 at 10:57 AM, Bassel Safadi wrote:
> eval is too dangerous unless we exclude every single bad script. using the
> php parser that is written in php will enable us to to create parser
eval is too dangerous unless we exclude every single bad script. using the
php parser that is written in php will enable us to to create parser trees
which will help aiki to understand what the custom php script written by
the user is trying to do
--
Bassel Safadi | http://bassel.ws
Skype: i.know.
Might as well just allow an eval() then for php code in a widget, but
I think we should allow for selection of a markup per-widget, so we
can have more specific control over this. I still want to think thru,
what are the real security considerations for just allowing php?
Jon
On Thu, Feb 23, 2012
here is a cool project https://github.com/nikic/PHP-Parser
we can get inspired or use this for aiki markup. we should just
allow peaceful php code to be excuted inside the widgets instead of
inventing new markup. it's easier to just write php.
--
Bassel Safadi | http://bassel.ws
Skype: i.know.sy |
17 matches
Mail list logo
