[Zope-dev] Python Product Style - on-the-fly objects to DTML

2000-11-09 Thread Jim Washington

Hi, all

I have a project going that requires the users to fill-out many
different tabular data forms.

So, I thought I would develop yet another table-generator.  The main
class (descended from OFS.SimpleItem) has a reorderable list of
information (MT_ColumnInfo(Persistent)) about the columns (title, name,
type, size, etc.) and another reorderable list of information about the
rows (MT_RowInfo(Persistent)) (title, name), so that the column names
and row names can be put together and I do not have to worry about
getting R*C names right for each table.

Anyway, I do not want to return any of these classes to DTML for
processing.  I want another class, CellInfo, which has the concatenated
row and column names as name, and the type, size, etc. information from
the Column information.  A list of these with the title of the Row would
be a row_data, so what I have to work with in DTML is the
column_headings list and a list of row_data objects containing a list of
CellInfos. All of these can be generated on-the-fly, so should not need
to be descended from a Persistent Class.  Less stuff to change if the
table needs to be modified / reordered.

But:  In my usual trial-and-success blundering about, I find that unless
these objects participate in the security system, I get "the login
window that will not leave".  So, I descend these objects from
OFS.SimpleItem and give them default __ac_permissions__.  Everything
works as expected.  

Looking closer, I see that the thing really working is: 
descent from AccessControl.Role.RoleManager
and 
__allow_access_to_unprotected_subobjects__=1.

So I make these modifications, and everything seems fine. Allowing
access to unprotected subobjects is cool, since these are
non-persistent.

Now for the question:  What happened when I created un-attached
Persistent descendents on-the-fly while testing earlier?  I presume they
garbage-collected away when I was done with them. Is this correct?  I
have a nagging worry about ghost objects and the types of programming
errors that might create them.

-- 

Jim Washington

___
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 )




[Zope-dev] Where to send patches?

2001-09-10 Thread Jim Washington

Hi, All

Since the Collector is down, where do we send patches if we are not 
cvs-authorized?  I just discovered a not-too-clever hack to make the 
Find tab  recurse through methods of Z Classes, which the margin of this 
e-mail is too small to contain.

-- Jim Washington


___
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] Where to send patches?

2001-09-10 Thread Jim Washington

Michel Pelletier wrote:

On Mon, 10 Sep 2001 12:16:51 -0400
 Jim Washington [EMAIL PROTECTED] wrote:

Hi, All

Since the Collector is down, where do we send patches if we are not 
cvs-authorized?  I just discovered a not-too-clever hack to make the 
Find tab  recurse through methods of Z Classes, which the margin of
this 
e-mail is too small to contain.


Dude, don't jinx yourself.  I'm sure you don't want us to refer to this as Jim 
Washington's last patch. ;)

Ack!  I deserve that for playing the cleverness card.  Fortunately, I am 
not planning any duels anytime soon :)

The requested change does seem to work, and does not seem to break 
anything.  And it is probably bad to admit that Z Classes are somehow 
different enough to require special treatment in base Zope code.  FWIW, 
 my patch (against FindSupport.py in 2.4.1) is attached.  Consume at 
your leisure.

-- Jim Washington


*** FindSupport.py.orig Mon Sep 10 11:31:20 2001
--- FindSupport.py  Mon Sep 10 11:55:19 2001
***
*** 152,168 
  if hasattr(obj, 'aq_base'):
  base=obj.aq_base
  
! if not hasattr(base, 'objectItems'):
  return result
  try:items=obj.objectItems()
  except: return result
  
  try: add_result=result.append
  except:
  raise AttributeError, `result`
  
  for id, ob in items:
! if pre: p=%s/%s % (pre, id)
  else:   p=id
  
  dflag=0
--- 152,179 
  if hasattr(obj, 'aq_base'):
  base=obj.aq_base
  
! if not hasattr(base, 'objectItems') and not base.meta_type == 'Z Class':
  return result
+ 
+ if hasattr(base, 'objectItems'):
try:items=obj.objectItems()
except: return result
  
+ if base.meta_type == 'Z Class':
+   try:items=obj.propertysheets.methods.objectItems()
+   except: return result
+ 
+ 
  try: add_result=result.append
  except:
  raise AttributeError, `result`
  
  for id, ob in items:
! if pre: 
!   if base.meta_type == 'Z Class':
! p = %s/propertysheets/methods/%s % (pre,id)
!   else:
! p=%s/%s % (pre, id)
  else:   p=id
  
  dflag=0
***
*** 194,201 
  ):
  add_result((p, ob))
  dflag=0
! 
! if search_sub and hasattr(bs, 'objectItems'):
  self.ZopeFind(ob, obj_ids, obj_metatypes,
 obj_searchterm, obj_expr,
 obj_mtime, obj_mspec,
--- 204,211 
  ):
  add_result((p, ob))
  dflag=0
! #small edit here to add the or
! if search_sub and (hasattr(bs, 'objectItems') or bs.meta_type == 'Z 
Class'):
  self.ZopeFind(ob, obj_ids, obj_metatypes,
 obj_searchterm, obj_expr,
 obj_mtime, obj_mspec,



[Zope-dev] [Fwd: Re: [Zope] Python 2.1 for debian ?]

2001-10-03 Thread Jim Washington


Would it be smart to include the python header files in the zope binary 
distributions?  That would seem to solve a few problems for the 
individuals using them.

-- Jim Washington

 Original Message 
Subject: Re: [Zope] Python 2.1 for debian ?
Date: Wed, 03 Oct 2001 12:51:37 + (GMT)
From: Julián Muñoz Domínguez [EMAIL PROTECTED]
To: Jim Washington [EMAIL PROTECTED]



Thank you very very much ;-)

But it is not possible to compile extensions with zope binary
distributions, because it lacks some headers. Many products requires
compiling extensions, so that readdress me to need of Python 2.1 . 






___
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 )



[Zope-dev] More Zope 2.6 requests

2002-03-08 Thread Jim Washington

While we are asking, I have two things that I would consider valuable 
additions to Zope 2.6:

1.  UserSniffer.  Currently an External Method, but has functionality 
that should be available OOTB to assist making those (horrors!) 
browser-dependent hacks.  It has other uses, too, like explaining to 
clients that their browser is five years old and needs the free upgrade 
that is available.

2.  Support for HTTP_X_FORWARDED_FOR.  Many (most?) of us run zope 
behind Apache ProxyPass or Squid, and the Zope logs therefore save the 
ip address of the proxying machine rather than any semblance of where 
the client browser is.  I realize that other proxies do not always 
follow the rules, etc., etc., but I think that using 
HTTP_X_FORWARDED_FOR if not null would be better than a log full of 
192.168.1.1.

Apologies if these have already been discussed under another heading.

-- Jim Washington



___
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] more on the segfault saga

2002-03-14 Thread Jim Washington

Don't know if this helps, but the last three segfaults I have seen were 
right after someone logs in, during loading /manage.

Zope-2.5.0 Win32 binary on Win2k. The pop-up referenced the same 
instruction 0x1e13490a at the same memory address 0x005c all 
three times, saying 'memory could not be read.'

-- Jim Washington


___
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 )



Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of 2.6...

2002-04-10 Thread Jim Washington

Support for X-HTTPD-FORWARDED-FOR

Code for this is pretty simple:

modify 2 files, ZServer/medusa/http_server.py and 
lib/python/AccessControl/User.py

1.  To put the proxy-passed ip address in the zserver log,

Around line 269 in ZServer/medusa/http_server.py, add a method 
http_request::client_ip

def client_ip(self):
proxy_client = self.get_header('x-forwarded-for')
if proxy_client:
return proxy_client
else:
return self.channel.addr[0]

Then around line  294, change the statement that does logging to use the 
method.
self.channel.server.logger.log (
self.client_ip(),
' - %s [%s] %s %d %d %s %s\n' % (
name,
...

2.  If we want to get fancy about allowing authentication using that ip 
address like naked ZServers can do,

In lib/python/AccessControl/User.py, around line 1116,
change

if request.has_key('REMOTE_ADDR'):
   addr=request['REMOTE_ADDR']

to

if request.has_key('HTTP_X_FORWARDED_FOR'):
   addr=request['HTTP_X_FORWARDED_FOR']
elif request.has_key('REMOTE_ADDR'):
   addr=request['REMOTE_ADDR']

I do not believe this does anything to authentication that is not 
possible now regarding spoofed ip addresses, so probably not a major 
security headache.

Major possible problem I can think of:  I do not use ZEO, and have no 
idea what these changes might do there.  I do not have check-in 
privileges, and probably should not until I get a better clue of how cvs 
works :).

Anyway, here is the code FWIW.  Apologies that it is not a patch per se. 
 Now looking for a more clueful sponsor to take it from here to check-in 
(after vetting?)

-- Jim Washington

Brian Lloyd wrote:

...I sent out a note a while ago now trying to scare up 
some ideas on how to vet the current list of 2.6 proposals 
and get to a final plan. I didn't get much (any?) response :(

For a couple of things that were ready to go and fairly non
controversial (like Toby's unicode work), I put on the BDFL 
hat and said merge it!.

But there are still a lot of things on the proposed features 
that are undone, and some that are controversial enough that 
we need to get to closure on them.

I'll volunteer to convert the current proposed feature list 
into a draft plan, where the conversion boils down to 
adding some columns to the table:

Proposal - name and link to the proposal

Resources - who is working on it

Committed - Y/N whether the volunteers have committed to have
the implementation and docs done by the first week
in June. I'll fill in what I know has been committed
to, people can update this (or let me know and I'll 
do it), and anything that doesn't get a 'Y' in a 
reasonably short time will be put in the cooler.

Vetted - Y / N whether the community and / or the relevant BDFLs
 have come to some agreement on whether it *should* be 
 done. The list of items without a 'Y' will be our next 
 order of business. Getting to closure on those either 
 via the list, IRC, or whatever is the main block on the 
 critical path.

Status - Complete or incomplete 


I've taken a first stab at this. I've set the committed to 'Y' 
for those things that I know I've gotten commitments for. For 
those set to 'N', please let me know if you can commit to the 
date (or change it yourself in the wiki).

The updated plan is at:

http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures


Once we get the commitments up to date, we can start wrangling 
with the vetting...





___
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: Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of2.6...

2002-04-10 Thread Jim Washington



Correct me if I'm wrong, but this IMO makes spoofing against a naked 
ZServer a childs play. It's just adding a custom header to the request.
I also doubt that every reverse proxy overwrites this header, so 
zservers behind a proxy might also be hit.


Note:  this is using another web server to front for zope.  It turns out
to be fairly safe -- I have used a variant for quite a while and did
quite a bit of testing.  For short hand, I am going to call the other web
server apache.  Apache presumably uses something like getpeername to
fill in its idea of HTTP_X_FORWARDED_FOR or REMOTE_ADDR.  If the remote
user attempts to spoof it (by using hidden variables, or other HTTP
based techniques), the Zope server interprets this is a list, rather
than the expected string.  This is easy to detect, and in fact, if you
fail to handle it, you will probably simply error out.

If the attacker is using TCP spoofing, there is really not much you can
do at an application level.

On the other hand, I am now conviced that this is not an intelligent
thing to do, not even for presentation.  You already have Apache in
front, so why not use rewriting rules to make the URL distinguishable.
In this way, you can use one of the BASE or URL variables to determine
how the person got in.  This gives you pretty much the same level of
control (especially if you are worried only about internal/external) as
using IP addresses, without modifying either Zope or Apache.

Jim, Oliver

Thanks. I'm glad we have smart and knowledgeable people available to 
discuss these kinds of things.  My hope was that I could restrict my 
Manager account to a short list of machines, even through a squid or 
apache proxy.  Essentially add a third thing to have besides username 
and password.  Which I still think is better than just username and 
password, since Zope sees only *one* ip address coming from squid in the 
current situation.  I'll have to do some more thinking...

Regards,

-- Jim Washington



___
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: Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of2.6...

2002-04-11 Thread Jim Washington

Toby Dickenson wrote:

On Wed, 10 Apr 2002 12:16:35 -0400, Jim Washington [EMAIL PROTECTED]
wrote:

2.  If we want to get fancy about allowing authentication using that ip 
address like naked ZServers can do,


to

if request.has_key('HTTP_X_FORWARDED_FOR'):
  addr=request['HTTP_X_FORWARDED_FOR']
   elif request.has_key('REMOTE_ADDR'):
  addr=request['REMOTE_ADDR']


There are lots of things that use REMOTE_ADDR, and I guess they should
*all* use the proxy supplied address rather than the address of the
proxy. It makes sense to me that we should *replace* REMOTE_ADDR with
HTTP_X_FORWARDED_FOR at the earliest opportunity. (and create a
X_FORWARDED_BY)

Have you considered this approach?

Not yet, but I like the idea...  As with Oliver's reply, this I think 
would need some research.  I will be refining what I mean by support 
in the subject line shortly.



On Wed, 10 Apr 2002 18:59:38 +0200, Oliver Bleutgen [EMAIL PROTECTED]
wrote:

Correct me if I'm wrong, but this IMO makes spoofing against a naked 
ZServer a childs play.


Thats correct for a naked ZServer, or if behind a proxy which does not
sanitize the X-FORWARDED-FOR header. However it is safe if the request
comes from the right kind of proxy.

I think we need a new command line option to specify a list of IP
addresses which are trusted to run 'the right kind of proxy'. Zope
should only trust the X-FORWARDED-FOR header if the remote address is
one of its trusted proxies.

Pseudocode for handling this would be:

if request['REMOTE_ADDR'] in our_trusted_front_end_proxies:
request['HTTP_X_FORWARDED_BY'] = request['REMOTE_ADDR']
request['REMOTE_ADDR'] = request['HTTP_X_FORWARDED_FOR']

Excellent!  Except for command-line bloat.  With Matt Behrens's config 
proposal 
(http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration), 
this nevertheless could be workable.  Things are looking up.  Maybe. 
 U..., more research...

-- Jim Washington



___
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] robustness in management interface.

2003-02-07 Thread Jim Washington
Romain Slootmaekers wrote:


Hi,

The zope management interface has some robustness problems:

whenever you call manage_workspace (the normal way of managing a 
folder through the HTML Zope management interface) on a folder X, and 
some object y in that folder gives an error (fi, it has no title 
attribute, ) the whole folder becomes unmanageble. The only thing you 
can do at that point is to manually delete the problematic object by 
typing:

http:///X/manage_delObjects?ids=y

It seems to me that an object in a folder should not interfere with 
the management of the folder (at least, you should be able to throw 
the object out of the folder)


probably, a try/except or dtml-try in the right place fix this.


Or, you could assure that your objects all have titles (at least =) if 
you want them managed through the ZMI.  I have not seen this as a 
*requirement*, but every example of a zope object I have seen uses 
self.title=aString in __init__().  

It is also important to have titles for most cataloging.  Do you catalog 
your site?  Is not title a good thing for searching?  Might you catalog 
in the future?

Perhaps something for a BestPractices document(?) or wiki(?):

ZMI-manageable objects have a title attribute.  This is a string.

For a bit of context on the above, I put together a product that has 
title as a function (=[:30] of some content) some time ago.  I have been 
led to understand that this was a bad idea because it breaks some 
cataloging.

Your idea of dtml-try does have merit IMHO.  Should the ZMI really 
assume existence of anything other than id for objects?

-- Jim Washington


___
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 )


[Zope-dev] 501 NotImplemented in Zope 2.7 beta1

2003-08-15 Thread Jim Washington
I have been noticing a few 501 Not Implemented errors in the ZMI in 
2.7 beta.

The ones I have encountered are fixed by changing method=get to 
method=post in the html/dtml forms in e.g., Aqueduct.py.

I do not know the proper fix.
Also, this is weird enough (and perhaps merely a beta issue) that I 
could not decide the proper category in the bug collector or even what 
to search on to see if it had been reported previously.

So, consider this an FYI should anyone want to take a stab at fixing it 
or reporting it to the collector.

-- Jim Washington

___
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 )


Re: [Zope-dev] Zope on 64-bit Linux

2004-11-19 Thread Jim Washington
Larry Bates wrote:
Anyone out there successfully deploying and running Zope/CMF
on 64-bit Linux?  I'm looking at deploying AMD Opteron server
for hosting large Zope site and wanted to take advantage of
the speed and addressing capabilities if I could.  Specifically
I'd like to use RedHat Fedora Core 3 to run ZODB server and
ZEO Clients.  Any information would be greatly appreciated.
I have had success with zope2 and zope3 under 64-bit Gentoo Linux (2.6+) 
on a dual-Opteron box, but, of course, everything was compiled locally.

I suppose that this just means that it probably should work in Fedora 
Core 3.  I have no experience with Fedora, but it is probably worth a 
try.  I did not have to do anything special.

-Jim Washington
___
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 )


Re: [Zope-dev] Zope 3 without ZODB

2008-01-15 Thread Jim Washington
David Pratt wrote:
 Hi Chris. I was scanning the lists looking for posts similar to this.
 Were you successful in getting something like this to work? Anyone
 else document anything like this?

 I wrote a different main.py at some point about a year or so ago so
 both twisted clients and servers to could be started up using schemas
 for zconfig but am looking at possibilities without and with other non
 ZODB backends. I see Philip provided some clues for a mixin that could
 be used to glue the publisher's traversal mechanism together with an
 alternative storage.  Many thanks.

 Regards,
 David
I, too, am interested in this.

I'm taking a hard look at Sedna, http://modis.ispras.ru/sedna/ , a
multi-user XML database, which seems to fit my brain and my current
xml-ish bent a bit better than ZODB or rdb.

The python modules advertised don't work reliably enough for me, though
I have hacked together a protocol module that works to my satisfaction
so far.  If anyone wants to play with it, I'll throw it into the zif
collective on Sourceforge.  I'm thinking it may be possible to do an
elementtree (with full XPath!) interface to Sedna.

Anyway, Chris, any pointers on interfaces and configuration would be
very much appreciated.

-Jim Washington




___
Zope-Dev maillist  -  Zope-Dev@zope.org
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 )


Re: [Zope-dev] Zope 3 without ZODB

2008-02-15 Thread Jim Washington

Kapil Thangavelu wrote:
try ore.wsgiapp in pypi, you provide a root utility and traversal 
begins from there, the zodb is never opened. the default publication 
looks up the app root via utility and traversal continues from there. 
i've been using it successfully for a number of relational apps 
without the zodb.

Thanks, Kapil.

I spent a day on it, and never got past error pages.  Maybe my problem 
was starting with a zopeproject.


Anyway, it got me to take a good look at pylons, which I think is a 
better match for web development without ZODB.


I found I can still use adapters and utilities by using zope.component 
and zope.interface. :)


zif.sedna (newly beta2 in pypi) now has instructions for using its zope3 
database adapter with repoze.tm in pylons.


- Jim Washington
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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 )


Re: [Zope-dev] z3c.jsonrpc relase

2009-02-24 Thread Jim Washington
Roger Ineichen wrote:

 does someone have a good idea how we can handle an
 Unauthorized error with JSON-RPC? Should we use an error
 view concept and include a JavaScript method which can handle
 a special error code/message from the server and show a kind
 if login form?
 
 Any hints or does somebody know a framework which supports such 
 an implementation?

Hi Roger

Here's a hint I've been looking at.  Maybe it will give you some ideas.

http://ajaxpatterns.org/Direct_Login


- Jim Washington
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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 )