I think that will be super. The more plug-and-play you can make XFire to be, the more popularity it will gain. ;) (that's why I added XFIRE-916)
Going back to the WS-Security header stuff, I think that's totally insane :) but that's just my opinion lol. Regards On 3/21/07, Tomek Sztelak <[EMAIL PROTECTED]> wrote:
I think its a standard. Btw, i think i can add crytpoprovider with password encryption to distribution. On 3/21/07, Andres Bernasconi <[EMAIL PROTECTED]> wrote: > Finally, > > after adding UsernameToken security to a web service, I see that there is no > reference or mention in the WSDL that the service requires such > authentication method. (I don't know why but) I would have expected the WSDL > to show that it requires such header for incoming requests since it is part > of the "contract" I enfornce, but it is not there. > > Is this an XFire or a Standards thing? > > Regards > Andres B. > > > On 3/20/07, Tomek Sztelak <[EMAIL PROTECTED] > wrote: > > Sorry, i didn't have time to look , kinda busy these days :( But i'll > > check it sometime later. > > > > On 3/20/07, Andres Bernasconi <[EMAIL PROTECTED]> wrote: > > > Tomek, were you able to look at the XFIRE-916 ? do you think it's > feasible? > > > > > > Regards > > > AB > > > > > > > > > On 3/19/07, Andres Bernasconi < [EMAIL PROTECTED]> wrote: > > > > oki, thanks. If this is the "best practice", it might be good to have > an > > > "out-of-the-box" solution, ready for production environment. > > > > > > > > Regards > > > > Andrés B. > > > > > > > > > > > > > > > > On 3/19/07, Tomek Sztelak < [EMAIL PROTECTED]> wrote: > > > > > I don't use WS-Sec, so no :) But someone on mailing list mentioned > he > > > does. > > > > > > > > > > On 3/19/07, Andres Bernasconi < [EMAIL PROTECTED]> wrote: > > > > > > do YOU do it like that? > > > > > > > > > > > > > > > > > > On 3/19/07, Tomek Sztelak < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > > > > > > > > On 3/18/07, Andres Bernasconi < [EMAIL PROTECTED]> > wrote: > > > > > > > > Hi all, > > > > > > > > > > > > > > > > First of all, I wanted to suggest that the USER used in the > > > Encryption > > > > > > > > example of XFire's WS-Security page be set to "myAlias", since > > > that's > > > > > > the > > > > > > > > name used when the keys were created (instead of > myserveralias). > > > > > > > > > > > > > > > > Second, I wanted to know how all this would work in > production, > > > since > > > > > > this > > > > > > > > mechanism requires a password in the out_encryption.properties > > > file (and > > > > > > in > > > > > > > > the incoming properties file as well). Is there any way to > "hide" > > > this > > > > > > > > information? I guess it would make it hard to transition my > > > artifact > > > > > > (web > > > > > > > > application) from one environment to the other (dev, > integration, > > > > > > testing, > > > > > > > > prod...) > > > > > > > > > > > > > > You can create your own crypto provider ( probably extending > Merlin) > > > > > > > which will decrypt paswords from config files during loading. > > > > > > > > > > > > > > > and BTW, the example works perfectly ok. > > > > > > > > > > > > > > Thx :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > ----- > > > > > > > When one of our products stops working, we'll blame another > vendor > > > > > > > within 24 hours. > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe from this list please visit: > > > > > > > > > > > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > ----- > > > > > When one of our products stops working, we'll blame another vendor > > > > > within 24 hours. > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe from this list please visit: > > > > > > > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > ----- > > When one of our products stops working, we'll blame another vendor > > within 24 hours. > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > -- ----- When one of our products stops working, we'll blame another vendor within 24 hours. --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
