Wanikoo's version for XoopsCube

hi all;

in the demo site changes are:
1- form submition: post and get, try a search for get method and post a news for post method ( you can login using: demo,demo)
2- some redirections, sorry I was unable to do this from whithin the theme, so I made some changes to some files!
3- now you can use inline debug mode and view the resualts in the page. I will set the debug mod so you can test it. the great thing is that we can put the comment: <!--{xo-logger-output}--> in the out put and the debug data will be replaced by this comment.
4- getting left blocks on each request. so whene you go to the news module the block will show you extra menu items.


on theme.html top, now we have:



the javascript to handle this is:


The code has some comments that I wish helps you.

I am going to do something new: bringing the admin area to XOOPS front side, just like liferay portal.
and another idea is a full flash theme based on this aproach, I am thinking of this, any ideas? or do you think this is good or bad?

there is some other changes in the theme, I will put the file for download as soon as possible.

and thanks for all your comments;

@highlander
I found the article in French, so I need the English version.

Hello farshid,

Nice effort but a kind of patchwork that may creates some more security holes in XOOPS 2.0.16

Before you push further your efforts to make this old code alike a web 2.0 application, you should check the last javascript security anouncements.

Before the security holes are patched. Examine the key factors of vulnerabilities

.Ajax calls are scattered all over the browser page and can be invoked by respective events.
.Input and outgoing content validation confusion
.It is also possible to load JavaScript in the browser that forces the browser to make cross-domain calls and opens up security holes. This can be lethal and leveraged by virus and worms.
.Browsers can invoke an Ajax call and perform data serialization. It can fetch JS array, Objects, Feeds, XML files, HTML blocks and JSON. If any of these serialization blocks can be intercepted and manipulated, the browser can be forced to execute malicious scripts.
.Ajax opens up a backend channel and fetches information from the server and passes it to the DOM; (update browser’s page memory by calling customized functions or the eval() function) an insecure call can range from a session compromise to the execution of malicious content.

You'll found out there a lot more issues.
If google, yahoo and many other services using web 2.0 apps are been victims of this new vulnerabilities. Can you imagine... a XOOPS site...

Waiting for a XOOPS patch.

Hello xguide;

as I said this is just an idea, so I do not understand the term:
Quote:

as you mentioned this will open some security holes in xoops, well I think any code that is born may have some problems, as we can see there are many modules, and lets say generaly -codes-, not just in XOOPS but in many open source (and...) software that have such a problem.
I don't think I have added any thing to xoops! so I don't now why you should be afraid of security problems!

And about javascript, OK, maybe you are right but I don't know if there is some problems with javascript or not! and if yes that would be for all kind of scripts, Ajax or none Ajaxed ones!
do you think javascript generally have problems or just the new Ajax? and what should we do? do not use it?

at last if you think I am doing something wrong explain it to me more, this way you are helping me and saving me from falling!

I have an online site for demo, and I will be glad if you can show me some problems, I will learn for sure, and for others it is good too.

Hello farshid,

Quote:

You right. If we check XOOPS code we can see it's not completely object oriented. Part is old nuke, other part is Onokazu OO approach. Part is modules developers code style. Similar to any include of ajax library.

I've also check Wanikoo approach. As he says, XOOPS need a recode. To less vulnerabilities, just use the client dom-fx to improve interaction and user interface.

Until XOOPS 2.3 comes out and fixes the security holes.

Otherwise, great effort. We could apply this in a XOOPS intranet solution.

Xguide,

Are you indicating that generally there are vulnerabilites with AJAX or the way AJAX is implemented here?

Could you describe the vulnerabilities that you named a little bit more and what, if any, solutions to that?

Quote:

Yes.

Quote:

To keep XOOPS sites safety. No.


Never use XOOPS 2.0.16 without Mr. Gijoe module protector.

Wait for Mr. Skalpa XOOPS 2.3 release.


(hope the roadmap will be update soon)

Hi all;

I am a little busy, so sorry for the delay, I have just uploaded new theme: http://www.fanafzar.com/uploads/defaultaj.rar
just if you need Rico files: http://www.fanafzar.com/uploads/Rico.rar

NOTE: DO NOT USE THIS CODE ON ANY SITE - JUST FOR TESTING PURPOSE

after setting the theme to be used in preferences, we need to modify 2 files:

1- include/functions.php
around line 400 find:


add this code just after the above:


this will make redirected pages in the site work, but in the admin area this will make some problems;
and the problem is: when you are redirected in admin area, you will get an XML instead of the page,
so refreshing the page will get you to the right place.



2- /modules/system/templates/system_redirect.html

this is what your file should look like, this part is just like the previous part make us able to navigate while redirecting
throw Ajax:


just make sure the template is applied.

@Xguide:
yes you are right, protector module is needed, and this code is far from being used on a live site.
Thanks for your attention.

Damaster last work and get some usefulllinks and tips
here's a link about a starting point to fix some issues
we may found many others by testing scripts with 'Firebug'

http://wiki.script.aculo.us/scriptaculous/show/JSON

"As you can see, JSON couldn’t be much simplier and easy to use, but be aware that this method as is, is not the best solution keep in mind that it’s Java Script that get trough eval(), so be carefull. The Prototype library offer a method to parse json reponse, which does exacly the same thing as the script above.. It should not pose any security risks since the response, in theory, can only come from the same server from which the request was recieved, but sadly the theory and the real world are rarely the same. so better prevent than repair."

OK, I got what you mean, some how;
I want you to explain this a little bit more, cause I think an Ajax request could not call something out of its resided domain, correct me if I am wrong, what I have got from your post is that the problem here is the XML format used to send data which you suggest to be replaced with JSON, so please let me know what is the advantage of using JSON instead of XML, if your reasons are enough we will for sure make it work through JSON.

I will give JSON a try, I have not used it before but I know it is possible to use it with Rico and as you said it exists is prototype library; this way our next step will be to make these scripts work through JSON, not XML, If I have got what you mean we should out put page and blocks data via JSON... is that OK with you?
and do you think this will solve some problems?

I am waiting for any suggestions and data on the matter.