{9} All Changed Tickets (40 matches)

You can use this Report to see the last 40 changed tickets.

Ticket Summary Component Milestone Type Severity Created
Field Description
#1591 Security hole in Extended File Manager Plugins defect major 02/06/12
comment

The folder opened is restricted to the the example (demo) images distributed with Xinha, it is fine for somebody to delete these if the developer has not config'd Xinha, who cares, they are only example images.

You can not escape the example images folder unless the developer specifically changes the config to another folder. If they change the config to another folder, then they would also change the other configuration items for EFM to meet their security requirements.

This is only a problem in my view if you have a way to escape the demo images folder with default EFM configuration. Such a way is not proven to exist.

#1591 Security hole in Extended File Manager Plugins defect major 02/06/12
comment

You can see the problem in Xinha demo instalation, right here:

http://xinha.raimundmeyer.de/latest/plugins/ExtendedFileManager/backend.php?__plugin=ExtendedFileManager&__function=images&mode=image&viewtype=thumbview#

Isn't the permission to delete the files being denied by the operating system instead of the application? Should this screen appears called directly by the browser or should it only appears called by the editor? Isn't this the latest version?

#1591 Security hole in Extended File Manager Plugins defect major 02/06/12
cc

fernando.algarvio@…, guest

#1591 Security hole in Extended File Manager Plugins defect major 02/06/12
comment

No it doesn't. You must have a poor configuration or an old version. Ensure you properly configure your EFM and ImageManger?.

#1581 IE9 Fix Xinha Core defect major 09/30/11
comment

Thanks, that worked for me.

#1581 IE9 Fix Xinha Core defect major 09/30/11
severity

major

#1589 Strange issue with the string 'graph' in the body of a xinha enabled text area Xinha Core defect normal 11/29/11
comment

Disable all Xinha plugins and then try.

There's no reason that simply the word "graph" would cause such a thing in the Xinha core that I can think of.

And for the love of all that is holy, use a proper browser when you debug, Chrome or Firefox.

#1582 Wrong dialog size of ImageManager in FF7 Dialogs defect normal 10/04/11
comment

seems that problem was fixed with new FF update

#1582 Wrong dialog size of ImageManager in FF7 Dialogs defect normal 10/04/11
comment
#1298 CSS styling gets inserted into table cell after viewing source (Safari only) Browsers_Firefox 0.96 defect normal 10/09/08
comment

Changeset [1312].

#1298 CSS styling gets inserted into table cell after viewing source (Safari only) Browsers_Firefox 0.96 defect normal 10/09/08
comment

Recent versions of Firefox do in fact exhibit the problem, and a quick check of IE also shows some signs of it. I will apply Nicholas' fix to these modules, and also Opera (which I have not checked but at the least I don't see how it could hurt anything).

#1516 removal of several tags in html5 Xinha Core 0.96 defect normal 05/04/10
comment

Replying to gogo:

Also... it could be argued that in the context of a WYSIWYG editor like Xinha, using <font> <b> and <i> etc is the correct thing to do, when a user clicks the BOLD button in the editor, they are speifically saying "I want this to be in a bold typeface", not "I think this is strongly important", same goes for "I want this to be in an italic typeface" versus "I think this should be emphasized".

I don't mean to resurrect this bug, just fix this claim (though if this info causes it to be resurrected, I'm certainly not going to complain), since it's a fairly persistent misconception: <b> and <i> weren't deprecated. Of those three, only <font> is. See http://www.w3.org/TR/html4/index/elements.html

#1580 Pas de barre d'outils Xinha Core defect normal 06/03/11
comment
#1580 Pas de barre d'outils Xinha Core defect normal 06/03/11
comment

Je suis desole mais je parle francais un petite seulemant. J'ai essay votre page et il fonctionne sans erreur. Regardez la photo. Ce n'est pas un bug.

#1224 [confirmed] sevenbitclean? / ghost cursor error with html mode toggle (Firefox) Xinha Core 0.96 defect major 06/04/08
comment

It seems that Chrome 12.0.742.68 beta-m is producing the ghost cursor once more. If I toggle from WYSIWYG to HTML and back then save the contents and reload the content, the ghost cursor shows up where at the last cursor position.

#1576 Xinha does not work in IE9 Browsers_InternetExplorer defect blocker 04/09/11
comment

See comment by gogo for the fix: http://www.xinha.org/punbb/viewtopic.php?id=3782#p9491

#1576 Xinha does not work in IE9 Browsers_InternetExplorer defect blocker 04/09/11
description

See forum post http://www.xinha.org/punbb/viewtopic.php?id=3782

In IE9 xinha build 1263 onwards fail to load. They stop showing in the loading box.

Loading in progress. Please wait! Create Toolbar

Using IE developers tools I get the following error in the console... but not in compatibility mode when it works fine.

SCRIPT5002: Function expected XinhaCore?.js, line 1572 character 18

#1575 CharacterMap defunct popups Plugins defect normal 03/29/11
comment

changeset:1301

#1502 Create MootoolsFileManager plugin, combining ExtendedFileManager and ImageManager Plugins 0.97 enhancement normal 02/17/10
comment

changeset:1297

Update to enhance reliability and functionality of MootoolsFileManager?...

  1. A couple of race type conditions caused various issues with loading the MFM. Necessitated fixes to the assetLoader, reordering the scripts getting loaded, and adding a "Xinha._posturlcontent" method which performs a synchronous post.
  1. CSS fixes, including moving some styles from Xinha.css into the PersistentStorage? plugin, they did not apply to anything else. I think this plugin is dead and should be removed anyway.
  2. Add preselection of current image
  3. Split margin into L/R and T/B when using HSpace/VSpace
  4. Add documentation for HSpace/VSpace in config.php

Also snuck in a couple of other bugfixes/additions:

  1. add support for having attribute "onxinhaready" on a textarea
  2. some PHP deprecation issues in the old ExtendedFileManager and ImageManager
  3. add a skin.xml to blue-look skin

Note: This is an older version of MFM, I am about to create a branch to work on bringing in a large update to MFM in a couple of stages.

#1574 Editor flashes and goes grey Website defect major 03/21/11
comment

Do not use Xinha in cross domain situations, you will get permission issues. Your code specifies 

<script type="text/javascript">
    _editor_url  = "http://tatteredwindow.net/admin/xinha/"  // (preferably absolute) URL (including trailing slash) where Xinha is installed
    _editor_lang = "en";      // And the language we need to use in the editor.
    _editor_skin = "silva";   // If you want use a skin, add the name (of the folder) here
  </script>
  <script type="text/javascript" src="http://tatteredwindow.net/admin/xinha/XinhaCore.js"></script>

But you are using www.tatteredwindow.net to access your system.

#1573 IE8 + doctype adds extra style attribute Xinha Core defect normal 03/16/11
comment

In XinhaCore? try switching between the two different getHtmlMethod options

Search for this.getHtmlMethod = 'DOMwalk'; or this.getHtmlMethod = 'TransformInnerHTML'; and change appropriately.

Also, from memory IE 8 has two modes "Standards" and "Compatability", try switching between them (button in the IE address bar from memory) and see if it makes a difference.

If you are seeing this in DOMWalk, there is some special case for IE8 there, but I don't see how it would produce this problem.

#1573 IE8 + doctype adds extra style attribute Xinha Core defect normal 03/16/11
comment

Thanks Gogo,

I applied the suggested changes and tested again. Still no dice. The same symptoms, works in IE8 without doctype, but is still broken with a doctype.

Uploaded the new testcase with the entitized textarea contents.

#1573 IE8 + doctype adds extra style attribute Xinha Core defect normal 03/16/11
comment

Your HTML is invalid, this may or may not affect the problem at hand.

Please read this...

http://trac.xinha.org/wiki/Entize

and then fix your testcase/code and see if it makes a difference to this particular problem for you.

#1573 IE8 + doctype adds extra style attribute Xinha Core defect normal 03/16/11
comment
#1573 IE8 + doctype adds extra style attribute Xinha Core defect normal 03/16/11
summary

IE8 + doctype adds extra style attribute

#1570 I can see subdirectories with php files and everything! Xinha Core defect normal 02/23/11
comment

Not a bug. RTFM http://trac.xinha.org/wiki/Linker

#1570 I can see subdirectories with php files and everything! Xinha Core defect normal 02/23/11
cc

deane@…

#1570 I can see subdirectories with php files and everything! Xinha Core defect normal 02/23/11
comment

Replying to guest:

From within the editor, I can click on the Link icon to try and add a link, and it gives me a directory listing of my Xinha directory including contrib, examples, modules, plugins, popups, etcetera. How dare it! Please tell me how to get rid of this horrible directory listing. I am appalled! I feel violated! I can't have them being able to read ANY of my directories!

As it turns out you can at least curb what is shown by overriding /plugins/scan.php ! Very SCARY GUYS! GRRR.

#1569 osCommerce Integration Plugins enhancement normal 01/11/11
comment

Ask osCommerce, not us.

#1568 TransformInnerHTML.js replace error Xinha Core defect normal 12/17/10
comment

correct: appears 3 times.

#1566 List behavior on Chrome is bad Xinha Core defect normal 12/02/10
comment

My guess would be probably a bug in WebKit? itself rather than any part of Xinha.

#1563 No way to set `showLoading=false` if using XinhaLoader.js Xinha Core defect normal 11/26/10
comment
#1564 Cache-busting config option Xinha Core enhancement normal 11/27/10
comment

Seems a good idea.

Should be off by default of course.

#1563 No way to set `showLoading=false` if using XinhaLoader.js Xinha Core defect normal 11/26/10
comment

I attached a patch to XinhaLoader.js which lets the user specify which editors should have loading messages, using a new global variable. I also attached an example XinhaConfig.js that shows how to use this.

But, I am leaning towards the last approach in the ticket:

Of course, it could also be argued that if you're using XinhaLoader.js you are accepting the unconditional existence of loading messages.

Part of the reason I'm leaning towards this is that I don't think we should be adding new functionality to XinhaLoader.js; I'd rather try to deprecate it (though I don't know how realistic that is)

#1563 No way to set `showLoading=false` if using XinhaLoader.js Xinha Core defect normal 11/26/10
comment

I attached a patch to XinhaLoader.js which lets the user specify which editors should have loading messages, using a new global variable. I also attached an example XinhaConfig.js that shows how to use this.

But, I am leaning towards the last approach in the ticket:

Of course, it could also be argued that if you're using XinhaLoader.js you are accepting the unconditional existence of loading messages.

Part of the reason I'm leaning towards this is that I don't think we should be adding new functionality to XinhaLoader.js; I'd rather try to deprecate it (though I don't know how realistic that is)

#1523 Dynamically create textarea and then init Xinha to it Xinha Core 0.97 enhancement normal 06/02/10
comment

I'd close it, this is a matter for the person who wants to use Xinha, what they want to do simply requires a different way of using Xinha than is described in the Newbie guide.

We don't describe every possible way that somebody might fancy to use Xinha :)

#1529 Security Issues in XINHA WYSIWYG 0.96.1 Xinha Core 0.97 defect normal 07/13/10
comment

Replying to ejucovy:

Hmm, have these vulnerabilities been addressed by the changes in 0.96.1 (#1515, #1518)? Or is this ticket still active?

I emailed them when they posted, this is what they said...

Hello,

first of all thank for the fast answer.

We at MajorSecurity? have discovered some vulnerabilities in one of the Plugins in XINHA WYSIWYG Editor version 0.96.1, which can be exploited by malicious people to conduct cross-site scripting attacks. Input passed directly to the "mode" parameter in "backend.php" of the "ExtendedFileManager" Plugin is not properly sanitised before being stored and returned to the user. This can be exploited to execute arbitrary HTML and script code in a user's browser session in context of an affected site.

Proof of Concept: 

http://localhost/xinha-0.96.1/plugins/ExtendedFileManager/backend.php?__plugin=ExtendedFileManager&__function=manager&backend_data[data]=a%3A9%3A{s%3A17%3A%22max_foldersize_mb%22%3Bi%3A10%3Bs%3A9%3A%22files_dir%22%3Bs%3A38%3A%22%2Fwww%2Fhtdocs%2Fw007ec76%2Fx_examples%2Fimages%22%3Bs%3A10%3A%22images_dir%22%3Bs%3A38%3A%22%2Fwww%2Fhtdocs%2Fw007ec76%2Fx_examples%2Fimages%22%3Bs%3A9%3A%22files_url%22%3Bs%3A19%3A%22%2Fx_examples%2Fimages%2F%22%3Bs%3A10%3A%22images_url%22%3Bs%3A19%3A%22%2Fx_examples%2Fimages%2F%22%3Bs%3A21%3A%22images_enable_styling%22%3Bb%3A0%3Bs%3A21%3A%22max_filesize_kb_image%22%3Bi%3A200%3Bs%3A20%3A%22max_filesize_kb_link%22%3Bs%3A3%3A%22max%22%3Bs%3A23%3A%22allowed_link_extensions%22%3Ba%3A12%3A{i%3A0%3Bs%3A3%3A%22jpg%22%3Bi%3A1%3Bs%3A3%3A%22gif%22%3Bi%3A2%3Bs%3A2%3A%22js%22%3Bi%3A3%3Bs%3A3%3A%22pdf%22%3Bi%3A4%3Bs%3A3%3A%22zip%22%3Bi%3A5%3Bs%3A3%3A%22txt%22%3Bi%3A6%3Bs%3A3%3A%22psd%22%3Bi%3A7%3Bs%3A3%3A%22png%22%3Bi%3A8%3Bs%3A4%3A%22html%22%3Bi%3A9%3Bs%3A3%3A
%22swf%22%3Bi%3A10%3Bs%3A3%3A%22xml%22%3Bi%3A11%3Bs%3A3%3A%22xls%22%3B}}&backend_data[session_name]=PHPSESSID&backend_data[key_location]=Xinha%3ABackendKey&backend_data[hash]=582686c520f11fc779ada11642d7e3b5711a3c37&PHPSESSID=599be382ae27a9a75cd2e7d039b2098a&mode="<script>alert(/XSS/)</script>

Solution: Web applications should never trust on user generated input and therefore sanatize all input. Edit the source code to ensure that input is properly sanitised.

I don't remember if I did anything about it.

#1541 Allow more flexible configuration for formatblock options Xinha Core 0.97 defect normal 08/28/10
comment

After mulling it over for a few days I'm still pretty happy with this approach, so I've committed r1296 which adds the xinha_config.formatblockDetector option.

#1523 Dynamically create textarea and then init Xinha to it Xinha Core 0.97 enhancement normal 06/02/10
comment

Hmm, I don't understand this ticket, can someone describe a way to set up and reproduce a specific error here?

#1523 Dynamically create textarea and then init Xinha to it Xinha Core 0.97 enhancement normal 06/02/10
description

Desktop-like apps work with windows that can be created after app has started and that can be closed en opened again on demand. On this kind of windows textareas can be placed that must be transformed in Xinha-editors. That can be done with Xinha.init and/or Xinha.replace, but problems arise with the standard way of setting and reading text from de editor(s). The way described in help/guide with xinha_editors doesn't work . I found out that __xinhas is global object that enumerates (and stores?) editors. Through a loop over this object it is possible to find the editor and set/get text.

It would be a great enhancement when Xinha is adjusted to this new way of developing of internetapps: to remove an editor when the window is closed form __xinhas object, to created or replace an already existing editor when a window is created and easily keeping track of the existing editors in the app.

Note: See TracReports for help on using and creating reports.