RE: [wsrp] What faults to throw when property writes are

I 
mainly agree but see comments below,

 

thanks, 

Andre

  
-----Original Message-----
From: Rich Thompson 
  [mailto:]
Sent: 04 April 2003 14:39
To: 
  
Subject: Re: [wsrp] What faults to throw 
  when property writes are

My opinions are intertwined with <rt/> 

Rich Thompson 

  
    
    

      
      Andre Kramer 
        <> 
        
04/04/2003 03:38 AM 

              
        To:     
            
        cc:       
          
      
          Subject:        [wsrp] What faults to throw 
        when property writes are

  

Yesterday, we said we would continue to use 
  this list for spec &
implementation discussion. So here goes one set of 
  questions I would be
interested to hear people's opinion on:

In 
  section 6.3.3 we say that "the producer MUST throw a fault message if 
  the
processing the interaction requires changing its persistent state" 
  if
"readOnly". We don't say what the fault MUST be. 
  PortletStateChangeRequired
I presume ... 

<rt>We talked about whether to specify the fault to throw and 
  decided to leave it up to the Producer. Interface.PortletStateChangeRequired 
  is certainly a leading candidate.</rt>

[Andre 
  Kramer]  And performBlockingInteraction declares a 
  PortletStateChangeRequired fault...

  

Later, we say that "Interface.PortletStateChangeRequired" MAY be 
  throw if
the "producer implements access control that prevents Portlets 
  from updating
persistent state". Surely that should be a security (Top 
  Level Security.)
exception ;-)

<rt>Why would that be a security exception? The scenario is that 
  a Portlet attempts to write a property that the Producer will not allow it to 
  write. Presumably the Producer informs the Portlet of this with an exception 
  and the Portlet decides whether it can proceed without having changed that 
  property or whether the invocation should fail. If the decision is to fail, 
  this statement encourages (but doesn't require) that the 
  Interface.PortletStateChangedRequired fault message be returned. Of course, it 
  is possible that the Portlet doesn't catch the Producer's exception and the 
  actual fault returned is a serialization of that internal 
  error.</rt>

[Andre Kramer] The words "access control" suggest a 
  security fault. I would hope to not expose internal errors. Also, see 
  last fault below where you suggest 
  Security.AccessDenied.

  
 
Also, 
  what actual fault should be thrown for the following cases (note that
not 
  all the operations declare a throws PortletStateChangeRequired)?

- a 
  Portlet attempts to set a property in getMarkup. 

<rt>Spec prohibits this. The Producer should throw an 
  exception to the Portlet on the attempt.</rt>

Should the producer 
  throw a fault or silently discard the update or generate
an error markup 
  fragment? 

<rt>The Portlet could 
  decide to return a fault instead of markup ... probably OperationFailed. But 
  fundamentally this would be a non-conformant Portlet</rt>
 
[Andre Kramer] I think we should have the 
  producer throw OperationFailed. As we specify producers, how 
  can we talk of non-conformant 
  portlets?

  

- a Consumer attempts to update a preference on a publicly offered 
  portlet.

Should the producer throw a fault or silently discard the 
  update or generate
an error markup fragment? Can we allow  writes in 
  some cases (admin level
consumers)?

<rt>I think a Security.AccessDenied fault message would be 
  appropriate. The detail message should specify that setting properties on 
  Producer Offered Portlets is not allowed.</rt>

[Andre 
  Kramer] OK

  

While we are not required to align all the above, 
  interop and testing would
be improved if we tighten property update fault 
  semantics.

[Andre Kramer] An implication of the above is that 
  PortletStateChangeRequired is likely to be used only 
  for portletState = ReadOnly.

  

regards,
Andre