persisting autobahnjs session after url change

#1

Hi,

I’m looking to build a page using the autobahnjs library where a user comes to a landing (html/http) page which prompts for logging in. Upon providing username and password, the page will go through the authreq process and authenticate the user. The authreq process itself already works without issues. After this authentication has been successful, the user will be re-directed to various pages on our site so they have access to other features, which we want to leverage the autobahn connection that was initially made for rpc and pubsub.

My question is: once the authentication process has been completed, how is this passed from one page to the next so authentication doesn’t have to be redone every time a new page is loaded?

One option I’m considering using is a shared webworker where the worker handles all autobahn communication, including authentication and rpc calls, and different pages load that worker, so it should store the authenticated info and subsequent pages will have access to it.

Something else we thought was serializing the connection object, but I assume the connection itself would already be closed unless there is a particular way to persist it.

Unfortunately, our site won’t allow for a single-page app approach, based on the libraries we’re using. Has anyone done anything like this already? Most examples I’ve seen involve using single-page apps and we want to avoid that method.

Thanks,

Steve

0 Likes

#2

My question is: once the authentication process has been completed, how
is this passed from one page to the next so authentication doesn't have
to be redone every time a new page is loaded?

When you leave the page that executed the JS which opened the WebSocket/WAMP connection and authenticated it, the WebSocket/WAMP connection is lost (and the authentication also).

One option I'm considering using is a shared webworker where the worker
handles all autobahn communication, including authentication and rpc

This seems to be the only option you have. Browser support for shared web workers is still limited though (http://caniuse.com/sharedworkers)

If you wanna go that route, you could wrap AutobahnJS. Better would probably be if AutobahnJS had an option to run in the background on a shared web worker .. not there currently.

calls, and different pages load that worker, so it should store the
authenticated info and subsequent pages will have access to it.

Something else we thought was serializing the connection object, but I
assume the connection itself would already be closed unless there is a
particular way to persist it.

Yes. There is no point in trying to "serialize" the connection: under the hood, there is a WebSocket native connection object.

Unfortunately, our site won't allow for a single-page app approach,
based on the libraries we're using. Has anyone done anything like this

Which and why does a client-side JS lib limits you rgd single-page?

already? Most examples I've seen involve using single-page apps and we
want to avoid that method.

Why? Just curious ..

/Tobias

···

Thanks,
Steve

--
You received this message because you are subscribed to the Google
Groups "Autobahn" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to autobahnws+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

0 Likes

#3

Hi Tobias,

Thank you for your quick reply!

It’s not the client-side js library that is restricting our ability to make a one-page app. Rather, we’re trying to integrate a couple other proprietary systems that don’t work well with single-page.

Thanks,

Steve

···

On Tue, Jun 25, 2013 at 12:30 PM, Tobias Oberstein tobias.o...@gmail.com wrote:

My question is: once the authentication process has been completed, how

is this passed from one page to the next so authentication doesn’t have

to be redone every time a new page is loaded?

When you leave the page that executed the JS which opened the WebSocket/WAMP connection and authenticated it, the WebSocket/WAMP connection is lost (and the authentication also).

One option I’m considering using is a shared webworker where the worker

handles all autobahn communication, including authentication and rpc

This seems to be the only option you have. Browser support for shared web workers is still limited though (http://caniuse.com/sharedworkers)

If you wanna go that route, you could wrap AutobahnJS. Better would probably be if AutobahnJS had an option to run in the background on a shared web worker … not there currently.

calls, and different pages load that worker, so it should store the

authenticated info and subsequent pages will have access to it.

Something else we thought was serializing the connection object, but I

assume the connection itself would already be closed unless there is a

particular way to persist it.

Yes. There is no point in trying to “serialize” the connection: under the hood, there is a WebSocket native connection object.

Unfortunately, our site won’t allow for a single-page app approach,

based on the libraries we’re using. Has anyone done anything like this

Which and why does a client-side JS lib limits you rgd single-page?

already? Most examples I’ve seen involve using single-page apps and we

want to avoid that method.

Why? Just curious …

/Tobias

Thanks,

Steve

You received this message because you are subscribed to the Google

Groups “Autobahn” group.

To unsubscribe from this group and stop receiving emails from it, send

an email to autobahnws+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

0 Likes