PDA

View Full Version : One common log-in for several apps



Per Thomson
2-Oct-2007, 08:44 AM
Yes, sounds stupid but here is the situation:

It's about some different workspaces (AJAX Web Apps) that are identical,
only thing that's differ are Virtual directory names.
'Above' those apps it's need for a 'Main' app that can inspect all of those
sub applications and do a little more on it's own 'main'-tables which
doesn't exist for the sub level apps.

The operator at the 'Main' app need to have direct access to sub apps
without log-in. With other words, a log-in at 'Main' app level should also
give access to a sub-level app.

The tables for User and Session can be common for all apps and located in
the workspace for 'Main'. By use of URL's (operator select application from
an application table in worksapce 'Main') it's possible to change from Main
to a sub application. But how do I avoid that the user is redirected to do a
new log-in at the sub level. With other words, I have to tell the sub
application that the user is already logged in. How do I do this?
(It's assumed strict log-in control like the Contact example.)

Kind Regards
Per T

Harm Wibier
2-Oct-2007, 10:04 AM
It isn't that stupid if you have a good reason for having different
applications! If it can be integrated into one application with more entry
points (multiple virtual directories pointing to the same AppHtml folder).

A solution might be in setting the Response.Cookies("domain")
(http://msdn2.microsoft.com/en-us/library/ms524757.aspx) to share the
cookies containing the session information between the sites.

--
Regards,


Harm Wibier
Data Access Europe B.V.
http://www.dataaccess.nl/


"Per Thomson" <per.thomson@wtnord.net> wrote in message
news:hNUF0nPBIHA.4204@dacmail.dataaccess.com...
> Yes, sounds stupid but here is the situation:
>
> It's about some different workspaces (AJAX Web Apps) that are identical,
> only thing that's differ are Virtual directory names.
> 'Above' those apps it's need for a 'Main' app that can inspect all of
> those
> sub applications and do a little more on it's own 'main'-tables which
> doesn't exist for the sub level apps.
>
> The operator at the 'Main' app need to have direct access to sub apps
> without log-in. With other words, a log-in at 'Main' app level should also
> give access to a sub-level app.
>
> The tables for User and Session can be common for all apps and located in
> the workspace for 'Main'. By use of URL's (operator select application
> from
> an application table in worksapce 'Main') it's possible to change from
> Main
> to a sub application. But how do I avoid that the user is redirected to do
> a
> new log-in at the sub level. With other words, I have to tell the sub
> application that the user is already logged in. How do I do this?
> (It's assumed strict log-in control like the Contact example.)
>
> Kind Regards
> Per T
>
>

Pak
9-Oct-2007, 08:54 AM
Another solution would be to share the tables between the various
applications, so that the USER and SESSION tables actually point to the
same data file/table. This is probably easier to do using a non-embedded
backend (e.g. SQL Server).

This way, all webapps use the user session validation code, and simply
redirect the user to the security webapp if the user hasn't logged in or
if their session is invalid.

Regards,

Pak Chan


Harm Wibier wrote:
> It isn't that stupid if you have a good reason for having different
> applications! If it can be integrated into one application with more entry
> points (multiple virtual directories pointing to the same AppHtml folder).
>
> A solution might be in setting the Response.Cookies("domain")
> (http://msdn2.microsoft.com/en-us/library/ms524757.aspx) to share the
> cookies containing the session information between the sites.
>

Bob Worsley
13-Jun-2011, 02:25 PM
Going back to this topic for a minute...

I have the need for a single sign-on to multiple webapps. I had the thought to create a webapp just for the user and session tables which would be then common to all and just page to the particular Webapp that the user is permitted to enter. Maybe a third table that provides the URL(s) the user is allowed to access.

The idea of a common page header and session variables seems like it might work.

a) Has anyone done this yet?
b) Does this make practical sense?
c) What are any potential "gotchas"?
d) What are the security risks?