API Interface abstraction

6 views
Skip to first unread message

Kris

unread,
Mar 15, 2012, 6:46:38 AM3/15/12
to widgetstore
Hi All,

Have been playing around with this for a few days and I'm currently
wanting to consume the edukapp store services from the store interface
I already have.

Most of this works, the only difficulty is in login and session
management which is tied to the JSPs.

Is there some way we can abstract the session from the interface and
pass a session key in the REST api or something like that?

We would need client service binding by some shared secret for this to
be secure.

Cheers

Kris

Scott Wilson

unread,
Mar 15, 2012, 8:04:22 AM3/15/12
to widge...@googlegroups.com

I've created a session info API at /session that returns the "isAuthenticated" boolean flag, the user id and user name. Give that a go.

Sessions in servlet apps are managed using a JSESSIONID HttpCookie - if the client isn't hosted in the same container (though it has to have the same origin) we could return a session token on successful login and instruct tomcat to use querystring JSESSIONID params.

>
> Cheers
>
> Kris

Kris Popat

unread,
Mar 16, 2012, 7:23:13 AM3/16/12
to widge...@googlegroups.com

On 15 Mar 2012, at 12:04, Scott Wilson wrote:

> On 15 Mar 2012, at 10:46, Kris wrote:
>
>> Hi All,
>>
>> Have been playing around with this for a few days and I'm currently
>> wanting to consume the edukapp store services from the store interface
>> I already have.
>>
>> Most of this works, the only difficulty is in login and session
>> management which is tied to the JSPs.
>>
>> Is there some way we can abstract the session from the interface and
>> pass a session key in the REST api or something like that?
>>
>> We would need client service binding by some shared secret for this to
>> be secure.
>
> I've created a session info API at /session that returns the "isAuthenticated" boolean flag, the user id and user name. Give that a go.

Okay will do, thanks


>
> Sessions in servlet apps are managed using a JSESSIONID HttpCookie - if the client isn't hosted in the same container (though it has to have the same origin) we could return a session token on successful login and instruct tomcat to use querystring JSESSIONID params.

This is fine, the only case I can think of is if someone - at some point - wants to create a none web-based client. iPhone app or an application or exe.

>
>>
>> Cheers
>>
>> Kris
>

Reply all
Reply to author
Forward
0 new messages