oh! didn't see this before i clicked on send. so it was not so much a hassle after all :)
Regrads, Dumindu. On Feb 13, 2008 2:06 PM, Senaka Fernando <[EMAIL PROTECTED]> wrote: > Hi all, > > I have added this fix into the head. By default, the Transport Headers > would not be exposed to a Service. Instead you will have to enable it in > the axis2.xml. Refer the axis2_manual on the svn head - the axis2.xml > section. Or modify the "<parameter name="exposeHeaders" > locked="true">false</parameter>" to "<parameter name="exposeHeaders" > locked="true">true</parameter>" > > Regards, > Senaka > > > > Hi Kaushalye, > > > > I think you are correct. I'm currently investigating the way we could read > > a param from the axis2.xml inside core_utils.c. > > > > Regards, > > Senaka > > > >> Senaka Fernando wrote: > >>>> On Feb 12, 2008 5:29 PM, Kaushalye Kapuruge <[EMAIL PROTECTED]> > >>>> wrote: > >>>> > >>>>> Senaka Fernando wrote: > >>>>> > >>>>>> Hi again, > >>>>>> > >>>>>> Also adding to this discussion, we must be fair to REST users too, > >>>>>> Kaushalye and that makes sense. :)... > >>>>>> > >>>>>> > >>>>>> > >>>>> :) Yes. But still I do not accept exposing the password even for REST > >>>>> users. > >>>>> I mean this is transport level authentication. The call come to the > >>>>> service after the transport layer authentication is done. So let's > >>>>> keep > >>>>> the authentication logic there. > >>>>> > >>>> Yes, in a strict sense, exposing transport headers is a violation of > >>>> concern. However, pragmatically, this is too much information hidden > >>>> from the service, specially in REST world. Why don't we allow the user > >>>> to decide if this functionality is needed? > >>>> > >>>> I would suggest adding another param in the axis2.xml. In default > >>>> configuration it will not be enabled, and if someone intends to use > >>>> this feature he will have to enable it using the axis2.xml. Any > >>>> comments? > >>>> > >>> > >>> Hi Dumindu, > >>> > >>> The decision should be made inside core_utils.c. I believe that it > >>> would > >>> be a great deal of hassle if we are to include it the axis2.xml, and > >>> propagate it to there. Also, if it is configurable, it should be a > >>> service > >>> level configuration. Therefore, I believe it is better to have this > >>> inside > >>> a #ifdef block. Therefore, the user will have to compile it allowing > >>> this > >>> functionality. Isn't that better? Also, this axis2.xml based filtering > >>> wouldn't be required, if the user wishes to use this he may simply use > >>> it, > >>> or just leave it as it is. It doesn't make any difference to our logic. > >>> > >> But if I install with default options and need to allow http headers to > >> be accessed in a later day(accidentally seeing this thread for example), > >> I would rather prefer to add an entry to axis2.xml. ;-) > >> -Kau > >>> Regards, > >>> Senaka > >>> > >>> > >>>> -- > >>>> Dumindu Pallewela > >>>> http://blog.dumindu.com > >>>> GPG ID: 0x9E131672 > >>>> > >>>> WSO2 | "Oxygenating the Web Service Platform" | http://wso2.com > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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] > >>> > >>> > >>> > >> > >> > >> -- > >> http://blog.kaushalye.org/ > >> http://wso2.org/ > >> > >> > >> --------------------------------------------------------------------- > >> 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] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Dumindu Pallewela http://blog.dumindu.com GPG ID: 0x9E131672 WSO2 | "Oxygenating the Web Service Platform" | http://wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
