On Wed, Jul 9, 2008 at 9:40 AM, Sanka Samaranayake <[EMAIL PROTECTED]> wrote:

>
>
> On Mon, Jul 7, 2008 at 7:39 PM, Nandana Mihindukulasooriya <
> [EMAIL PROTECTED]> wrote:
>
>> Hi Glen,
>>
>> - Let's aim to get 1.4.1 out the door at the end of next week, i.e. July
>>> 18th (is that enough time, Nandana?).
>>
>>
>> I  think we have to check Sanka's input on this. He will be fixing the
>> major issue in policy.
>>
>
>
> IMO, proper fix would be to improve Axis2 Dispatchers to set the
> AxisBindings in the MessageContext during the dispatch phase based on
> properties of incoming message even if client request came to the old format
> of service URL. For example for a message that came to older format of the
> service URL, the Dispatches can decide whether it belongs to the SOAP11 or
> SOAP12 or HTTP binding based on envelope namespace URI and content type .
> That way effective policy calculation will always happen based on the
> AxisBindings which will ensure the application of security irrespective of
> the format of service URL.
>

Seems to be good. What happens,
1. There is not SOAP 11Binding for a SOAP 11 message
2. There are two SOAP 11 Bindings for a SOAP 11 message.

I think in both cases we have to throw an exception.

thanks,
Amila.

>
>
> Thanks,
> Sanka
>
>
>
>
>
>>
>>
>>  - As always it's good to go through at least one RC so people can kick
>>> the tires, check the artifacts, etc.  So let's aim to get the RC out by
>>> Tuesday the 15th.
>>
>>
>> +1 for the RC.
>>
>> thanks,
>>  nandana
>>
>> Davanum Srinivas wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Exactly what i was afraid of :( Sigh! this is a *very* slippery slope.
>>>>
>>>> - -- dims
>>>>
>>>> Amila Suriarachchi wrote:
>>>> | On Mon, Jul 7, 2008 at 6:03 PM, Davanum Srinivas <[EMAIL PROTECTED]>
>>>> wrote:
>>>> |
>>>> |> Nandana,
>>>> |>
>>>> |> +1 from me for you to be the Release Manager for 1.4.1
>>>> |
>>>> |
>>>> | + 1 from me.
>>>> |
>>>> |>
>>>> |> IMHO, we should use 1.4 branch. The *ONLY* change should be the
>>>> |> security change. Nothing more.
>>>> |
>>>> | I think we need to fix any possible other critical issues as well.
>>>> | eg. https://issues.apache.org/jira/browse/AXIS2-3870
>>>> | This is a memory leak and we need to fix this.
>>>> |
>>>> | thanks,
>>>> | Amila.
>>>> |
>>>> |
>>>> |
>>>> |>
>>>> |> thanks,
>>>> |> dims
>>>> |>
>>>> |> On Mon, Jul 7, 2008 at 6:50 AM, Nandana Mihindukulasooriya
>>>> |> <[EMAIL PROTECTED]> wrote:
>>>> |>> I would like to volunteer to be the release manager for Axis2
>>>> 1.4.1.
>>>> |>>
>>>> |>> I think we can fix the critical issues in the 1.4 branch (or a 1.4.1
>>>> |> branch
>>>> |>> ) and do the 1.4.1 release. I don't think doing 1.4.1 from the trunk
>>>> is
>>>> |> the
>>>> |>> appropriate way as trunk is now java 1.5 and has lot of major
>>>> changes
>>>> |> after
>>>> |>> Axis2 1.4 . However we can fix any issues that are not already fixed
>>>> in
>>>> |> the
>>>> |>> trunk at the same time when we fix those in the branch.
>>>> |>>
>>>> |>> Hope this is oky with Axis2 release guidelines.
>>>> |>>
>>>> |>> thanks,
>>>> |>> nandana
>>>> |>>
>>>> |>> On Tue, Jul 1, 2008 at 6:39 PM, Davanum Srinivas <[EMAIL PROTECTED]
>>>> >
>>>> |> wrote:
>>>> |>>> IMHO, The logic is the same as for blockers. If there is a work
>>>> |>>> around, it's not a blocker. So i am +0 on a 1.4.1 since there is a
>>>> |>>> work around that can be documented.
>>>> |>>>
>>>> |>>> That said, If someone is willing to drive a 1.4.1 as the release
>>>> |>>> manager, please do go ahead.
>>>> |>>>
>>>> |>>> thanks,
>>>> |>>> dims
>>>> |>>>
>>>> |>>> On Tue, Jul 1, 2008 at 2:48 AM, Sanka Samaranayake <
>>>> [EMAIL PROTECTED]>
>>>> |>>> wrote:
>>>> |>>>> Hi,
>>>> |>>>>
>>>> |>>>> For the users who is already using 1.4 version, the workaround
>>>> would
>>>> |> be
>>>> |>>>> to
>>>> |>>>> define policies in services.xml without using
>>>> <wsa:PolicyAttachment>.
>>>> |>>>> Then
>>>> |>>>> the problem is that those policies will appear in <wsdl:PortType>
>>>> |> which
>>>> |>>>> is
>>>> |>>>> not correct but security will apply for both format of service
>>>> URLs.
>>>> |>>>>
>>>> |>>>> Hence +1 for fixing that issue and do 1.4.1 release.
>>>> |>>>>
>>>> |>>>> Thanks,
>>>> |>>>> Sanka
>>>> |>>>>
>>>> |>>>>
>>>> |>>>> On Mon, Jun 30, 2008 at 8:59 PM, Nandana Mihindukulasooriya
>>>> |>>>> <[EMAIL PROTECTED]> wrote:
>>>> |>>>>> Hi,
>>>> |>>>>>    There are few issues with Axis2 1.4 / Rampart 1.4 with the new
>>>> |>>>>> policy
>>>> |>>>>> configuration. The new policy configuration which allows us to
>>>> apply
>>>> |>>>>> policies to binding hierarchy is a great feature when in comes to
>>>> ws
>>>> |>>>>> security policy configuration. It allows security policies to be
>>>> |>>>>> attached to
>>>> |>>>>> the correct attachment points. But there are few issues that need
>>>> to
>>>> |> be
>>>> |>>>>> fixed in Axis2 1.4. I will list them below.
>>>> |>>>>>     1.) If we configure security using new configuration, service
>>>> can
>>>> |>>>>> be
>>>> |>>>>> accessed without security.
>>>> |>>>>>          In Axis2 1.4, a service is exposed in two EPRs (consider
>>>> |> SOAP
>>>> |>>>>> 1.1
>>>> |>>>>> binding).
>>>> |>>>>>            eg.
>>>> |>>>>>
>>>> |>>>>>
>>>> |>>>>>
>>>> |>
>>>> http://localhost:8080/axis2/services/SecureService.SecureServiceHttpSoap11Endpoint
>>>> |>>>>>
>>>> http://localhost:8080/axis2/services/SecureService
>>>> |>>>>>           But if we you set the policies using the new
>>>> configuration,
>>>> |>>>>> if
>>>> |>>>>> you do a web service call to the older EPR, you can access the
>>>> |> service
>>>> |>>>>> without any security even though it is secured using the binding
>>>> |>>>>> hierarchy.
>>>> |>>>>> This happens because if we call the old EPR, it is not dispatched
>>>> to
>>>> |> a
>>>> |>>>>> binding. But this leaves the service vulnerable. I think we
>>>> should
>>>> |>>>>> dispatch
>>>> |>>>>> to one of the bindings may be using soap envelope version if we
>>>> have
>>>> |>>>>> only
>>>> |>>>>> one binding with that soap version. We should have a way to
>>>> dispatch
>>>> |>>>>> messages which comes to old EPR to one of the bindings else we
>>>> should
>>>> |>>>>> have
>>>> |>>>>> an option to disable that EPR.
>>>> |>>>>>
>>>> |>>>>>     2.) In the out flow, policies are not set correctly in the
>>>> |> binding
>>>> |>>>>> message.
>>>> |>>>>>           This is fixed in the trunk but this bug is there in
>>>> Axis2
>>>> |>>>>> 1.4.
>>>> |>>>>>
>>>> |>>>>>    So the option we have is to configure security using the old
>>>> |>>>>> configuration. But then the problem is policies are attached to
>>>> the
>>>> |>>>>> port
>>>> |>>>>> type which is the correct way to do if we have policies using
>>>> |>>>>> <service>,<operation><message> tags. But this makes Axis2 not
>>>> |>>>>> interoperable
>>>> |>>>>> as security policies should be attached to binding hierarchy
>>>> |> according
>>>> |>>>>> WS
>>>> |>>>>> Security policy specification. Ideally we should always use the
>>>> new
>>>> |>>>>> configuration to apply security. And code generation also doesn't
>>>> |> work
>>>> |>>>>> correctly when the policies attached to the port type (polices
>>>> are
>>>> |> not
>>>> |>>>>> correctly attached to the stub).
>>>> |>>>>>
>>>> |>>>>>    So I think it would be great if can consider a Axis2 1.4.1
>>>> with
>>>> |>>>>> these
>>>> |>>>>> things fixed.
>>>> |>>>>>
>>>> |>>>>> thanks,
>>>> |>>>>> nandana
>>>> |>>>>
>>>> |>>>> --
>>>> |>>>> Sanka Samaranayake
>>>> |>>>> WSO2 Inc.
>>>> |>>>>
>>>> |>>>> http://sankas.blogspot.com/
>>>> |>>>> http://www.wso2.org/
>>>> |>>>
>>>> |>>>
>>>> |>>> --
>>>> |>>> Davanum Srinivas :: http://davanum.wordpress.com
>>>> |>>>
>>>> |>>>
>>>> ---------------------------------------------------------------------
>>>> |>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> |>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>> |>>>
>>>> |>
>>>> |>
>>>> |> --
>>>> |> Davanum Srinivas :: http://davanum.wordpress.com
>>>> |>
>>>> |> ---------------------------------------------------------------------
>>>> |> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> |> For additional commands, e-mail: [EMAIL PROTECTED]
>>>> |>
>>>> |>
>>>> |
>>>> |
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.6 (GNU/Linux)
>>>>
>>>> iD8DBQFIchYLgNg6eWEDv1kRAo7lAKDKyTiR50/aWOSuc9d7pVPHQPUoeACgkg+A
>>>> sQpm1+6vbyVf0CMQkT1aYXI=
>>>> =hpVj
>>>> -----END PGP SIGNATURE-----
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>
>
> --
> Sanka Samaranayake
> WSO2 Inc.
>
> http://sankas.blogspot.com/
> http://www.wso2.org/
>



-- 
Amila Suriarachchi,
WSO2 Inc.

Reply via email to