You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@xml.apache.org by Shimmie <sh...@shimmie.com> on 2002/07/17 12:12:42 UTC
Re: User authentication
Yeah,
I've done it this way. But now I'm changing it. If you do it that way you
have to maintain the sessions your self. Which is bullshit. Much better to
use the app server session management scheme.
Set your scope level to session and make SOAPContext your first parameter to
every server-side method. The context is populated automatically with
HttpRequest. From the request you can get the session. In the session you
can store on login, and check for in every other method, the User object.
Simon.
----- Original Message -----
From: "SB" <st...@cyberspace.org>
To: <so...@xml.apache.org>
Sent: Wednesday, July 17, 2002 8:45 PM
Subject: User authentication
> Have there been any convincing strategies for SOAP user authentication
> lately? Six months back, there werent any.
>
> Btw, did any one of you do the authentication in the following way:
> 1. Have a SOAP-service for login, input is username, and password.
> Inthe response, yo u will get a session id, whichc u will have to
> pass in the further soap messages.
>
> 2. The input of every soap service will have an additional field, for
> the session id. This id will autheticate the request.
>
>
> --st
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: User authentication
Posted by Shimmie <sh...@shimmie.com>.
Whether you use the App server's sessions management components (assuming
they were exposed) or you used your own, it doesn't matter, you would still
be managing the security and sessions and id generation and timeouts and
cookies and and and... I want the app server to do it all and I don't want
to know about it. Is the user logged in or not, thats all I care about.
> > Set your scope level to session and make SOAPContext your first
parameter to
> > every server-side method. The context is populated automatically with
> > HttpRequest. From the request you can get the session. In the session
you
> > can store on login, and check for in every other method, the User
object.
Doing the above, gives this to you. The only thing I'm concerned about is
that a FAQ I read (don't have the url handy) says that the HttpRequest is
only available in the SOAPContext when the client soap libs are apache too.
This would not be good (love standards...).
Anyway, I had a look at the code, and to me it looks like its there
regardless of the the client. Can anyone confirm or deny?
Simon.
----- Original Message -----
From: "SB" <st...@cyberspace.org>
To: <so...@xml.apache.org>
Sent: Wednesday, July 17, 2002 9:25 PM
Subject: Re: User authentication
> Quoting Shimmie (shimmie@shimmie.com):
> > Yeah,
> >
> > I've done it this way. But now I'm changing it. If you do it that way
you
> > have to maintain the sessions your self. Which is bullshit. Much better
to
> > use the app server session management scheme.
>
>
> Cant we access session management components of the appserver
> from the webapp? Is there any reason why an appserver would not
> want to give such access to a webapp?
>
>
> >
> > Set your scope level to session and make SOAPContext your first
parameter to
> > every server-side method. The context is populated automatically with
> > HttpRequest. From the request you can get the session. In the session
you
> > can store on login, and check for in every other method, the User
object.
> >
> > Simon.
> > ----- Original Message -----
> > From: "SB" <st...@cyberspace.org>
> > To: <so...@xml.apache.org>
> > Sent: Wednesday, July 17, 2002 8:45 PM
> > Subject: User authentication
> >
> >
> > > Have there been any convincing strategies for SOAP user authentication
> > > lately? Six months back, there werent any.
> > >
> > > Btw, did any one of you do the authentication in the following way:
> > > 1. Have a SOAP-service for login, input is username, and password.
> > > Inthe response, yo u will get a session id, whichc u will have to
> > > pass in the further soap messages.
> > >
> > > 2. The input of every soap service will have an additional field, for
> > > the session id. This id will autheticate the request.
> > >
> > >
> > > --st
> > >
> > > --
> > > To unsubscribe, e-mail:
<ma...@xml.apache.org>
> > > For additional commands, e-mail:
<ma...@xml.apache.org>
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
Re: User authentication
Posted by Shimmie <sh...@shimmie.com>.
Whether you use the App server's sessions management components (assuming
they were exposed) or you used your own, it doesn't matter, you would still
be managing the security and sessions and id generation and timeouts and
cookies and and and... I want the app server to do it all and I don't want
to know about it. Is the user logged in or not, thats all I care about.
> > Set your scope level to session and make SOAPContext your first
parameter to
> > every server-side method. The context is populated automatically with
> > HttpRequest. From the request you can get the session. In the session
you
> > can store on login, and check for in every other method, the User
object.
Doing the above, gives this to you. The only thing I'm concerned about is
that a FAQ I read (don't have the url handy) says that the HttpRequest is
only available in the SOAPContext when the client soap libs are apache too.
This would not be good (love standards...).
Anyway, I had a look at the code, and to me it looks like its there
regardless of the the client. Can anyone confirm or deny?
Simon.
----- Original Message -----
From: "SB" <st...@cyberspace.org>
To: <so...@xml.apache.org>
Sent: Wednesday, July 17, 2002 9:25 PM
Subject: Re: User authentication
> Quoting Shimmie (shimmie@shimmie.com):
> > Yeah,
> >
> > I've done it this way. But now I'm changing it. If you do it that way
you
> > have to maintain the sessions your self. Which is bullshit. Much better
to
> > use the app server session management scheme.
>
>
> Cant we access session management components of the appserver
> from the webapp? Is there any reason why an appserver would not
> want to give such access to a webapp?
>
>
> >
> > Set your scope level to session and make SOAPContext your first
parameter to
> > every server-side method. The context is populated automatically with
> > HttpRequest. From the request you can get the session. In the session
you
> > can store on login, and check for in every other method, the User
object.
> >
> > Simon.
> > ----- Original Message -----
> > From: "SB" <st...@cyberspace.org>
> > To: <so...@xml.apache.org>
> > Sent: Wednesday, July 17, 2002 8:45 PM
> > Subject: User authentication
> >
> >
> > > Have there been any convincing strategies for SOAP user authentication
> > > lately? Six months back, there werent any.
> > >
> > > Btw, did any one of you do the authentication in the following way:
> > > 1. Have a SOAP-service for login, input is username, and password.
> > > Inthe response, yo u will get a session id, whichc u will have to
> > > pass in the further soap messages.
> > >
> > > 2. The input of every soap service will have an additional field, for
> > > the session id. This id will autheticate the request.
> > >
> > >
> > > --st
> > >
> > > --
> > > To unsubscribe, e-mail:
<ma...@xml.apache.org>
> > > For additional commands, e-mail:
<ma...@xml.apache.org>
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
uddi gui
Posted by "Quan Z. (Michael) Sheng" <qs...@cse.unsw.edu.au>.
Hi,
I am using wstk3.1 now. when I tried to use uddi browser, there are some
problems:
1. first, there is an error information "error 404: file not found:
theme/xxxx." when I checked the directory, I found the package maks an
mistake with the file name. After I changed the name to xxxx,
localhost:80/uddigui works!
2. but it seems when I tried to find web services using names of the
business, it
does not work.
I don't know what version you are using now? If you have any experience
using this showcase package, specially regarding the above problem, please
let
me know.
Have a good time.
Cheers,
Michael.
--
----------------------------------------------------------------------------
Quan Z. (Michael) Sheng Office: 401-16 K-17
Kensington
Database Group Telephone: 61 2 9385 6908
School of Computer Sci. & Eng. Facsimile: 61 2 9385 5533
University of New South Wales Email:qsheng@cse.unsw.edu.au
Sydney, NSW 2052, Australia Webpage:www.cse.unsw.edu.au/~qsheng
----------------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
uddi gui
Posted by "Quan Z. (Michael) Sheng" <qs...@cse.unsw.edu.au>.
Hi,
I am using wstk3.1 now. when I tried to use uddi browser, there are some
problems:
1. first, there is an error information "error 404: file not found:
theme/xxxx." when I checked the directory, I found the package maks an
mistake with the file name. After I changed the name to xxxx,
localhost:80/uddigui works!
2. but it seems when I tried to find web services using names of the
business, it
does not work.
I don't know what version you are using now? If you have any experience
using this showcase package, specially regarding the above problem, please
let
me know.
Have a good time.
Cheers,
Michael.
--
----------------------------------------------------------------------------
Quan Z. (Michael) Sheng Office: 401-16 K-17
Kensington
Database Group Telephone: 61 2 9385 6908
School of Computer Sci. & Eng. Facsimile: 61 2 9385 5533
University of New South Wales Email:qsheng@cse.unsw.edu.au
Sydney, NSW 2052, Australia Webpage:www.cse.unsw.edu.au/~qsheng
----------------------------------------------------------------------------
Re: User authentication
Posted by SB <st...@cyberspace.org>.
Quoting Shimmie (shimmie@shimmie.com):
> Not following you... access to what in a webapp?
SessionManager sm = AppServer.instance().getSessionManager();
session_id = sm.createNewSession (user info)
return this id back.
and when u get it back, verify it using
bool x = sm.isValidSession(session_id)
and on logout, use
sm.removeSession (session_id)
In otherwords, if an app server can provide access
to its components using some standard interface, it
would have been great.
Re: User authentication
Posted by SB <st...@cyberspace.org>.
Quoting Shimmie (shimmie@shimmie.com):
> Not following you... access to what in a webapp?
SessionManager sm = AppServer.instance().getSessionManager();
session_id = sm.createNewSession (user info)
return this id back.
and when u get it back, verify it using
bool x = sm.isValidSession(session_id)
and on logout, use
sm.removeSession (session_id)
In otherwords, if an app server can provide access
to its components using some standard interface, it
would have been great.
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: User authentication
Posted by SB <st...@cyberspace.org>.
Quoting Shimmie (shimmie@shimmie.com):
> Yeah,
>
> I've done it this way. But now I'm changing it. If you do it that way you
> have to maintain the sessions your self. Which is bullshit. Much better to
> use the app server session management scheme.
Cant we access session management components of the appserver
from the webapp? Is there any reason why an appserver would not
want to give such access to a webapp?
>
> Set your scope level to session and make SOAPContext your first parameter to
> every server-side method. The context is populated automatically with
> HttpRequest. From the request you can get the session. In the session you
> can store on login, and check for in every other method, the User object.
>
> Simon.
> ----- Original Message -----
> From: "SB" <st...@cyberspace.org>
> To: <so...@xml.apache.org>
> Sent: Wednesday, July 17, 2002 8:45 PM
> Subject: User authentication
>
>
> > Have there been any convincing strategies for SOAP user authentication
> > lately? Six months back, there werent any.
> >
> > Btw, did any one of you do the authentication in the following way:
> > 1. Have a SOAP-service for login, input is username, and password.
> > Inthe response, yo u will get a session id, whichc u will have to
> > pass in the further soap messages.
> >
> > 2. The input of every soap service will have an additional field, for
> > the session id. This id will autheticate the request.
> >
> >
> > --st
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: User authentication
Posted by SB <st...@cyberspace.org>.
Quoting Shimmie (shimmie@shimmie.com):
> Yeah,
>
> I've done it this way. But now I'm changing it. If you do it that way you
> have to maintain the sessions your self. Which is bullshit. Much better to
> use the app server session management scheme.
Cant we access session management components of the appserver
from the webapp? Is there any reason why an appserver would not
want to give such access to a webapp?
>
> Set your scope level to session and make SOAPContext your first parameter to
> every server-side method. The context is populated automatically with
> HttpRequest. From the request you can get the session. In the session you
> can store on login, and check for in every other method, the User object.
>
> Simon.
> ----- Original Message -----
> From: "SB" <st...@cyberspace.org>
> To: <so...@xml.apache.org>
> Sent: Wednesday, July 17, 2002 8:45 PM
> Subject: User authentication
>
>
> > Have there been any convincing strategies for SOAP user authentication
> > lately? Six months back, there werent any.
> >
> > Btw, did any one of you do the authentication in the following way:
> > 1. Have a SOAP-service for login, input is username, and password.
> > Inthe response, yo u will get a session id, whichc u will have to
> > pass in the further soap messages.
> >
> > 2. The input of every soap service will have an additional field, for
> > the session id. This id will autheticate the request.
> >
> >
> > --st
> >
> > --
> > To unsubscribe, e-mail: <ma...@xml.apache.org>
> > For additional commands, e-mail: <ma...@xml.apache.org>
> >
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>