Not knowing the details completely, one cannot say what the user meant by session data, but in the situation described, a role could be analysed to switch between content databases, for example. So in this case, the information used to isolate the user would be the user's role -which would have come from being logged in to this app server to begin with, for example. So, a mix of changing content databases and perhaps module roots(based on role) could move the person to a different 'service' with different content on the same app server.
Yes, there is alot of reading/understanding/testing for someone to use the Enhanced HTTP features. But they were created and offered as a feature, and if used properly, they can be beneficial. Kind Regards, David Ennis David Ennis *Content Engineer* [image: HintTech] <http://www.hinttech.com/> Mastering the value of content creative | technology | content Delftechpark 37i 2628 XJ Delft The Netherlands T: +31 88 268 25 00 M: +31 63 091 72 80 [image: http://www.hinttech.com] <http://www.hinttech.com> <https://twitter.com/HintTech> <http://www.facebook.com/HintTech> <http://www.linkedin.com/company/HintTech> On 8 May 2015 at 02:46, David Lee <david....@marklogic.com> wrote: > I may be misunderstanding but I see "session data" and "REST" in the > same paragraph. > > What exactly do you mean by "session data". > > REST Services are not intended, nor directly manage server 'session state' > of the sort that is associated with Browser/interactive 'session' > > ( e.g. if you use xdmp:set-session-field() that creates a 'Session' which > is managed by browser cookies) > > > > You can have both browser based sessions and do rest from JS calls - but > you should not depend on, or attempt to make use of 'session state' from > REST calls - if it happens to work that is something that's not supported > and may or may not work in the future or in a different configuration. > > > > That out of the way - assuming your talking about some other kind of > 'session state' - maybe a database document which you pass the URL through > on REST calls ... that is a perfect use for the Enhanced HTTP server. > > It can be configured to switch DB, Modules DB, add and remove query > params, enforce additional security checks, switch between HTML,XML, JSON > error formats, change error handlers ... and of course 'rewrite' the URL. > REST, HTTP, XCC can all interop on the same port - in the same or different > 'applications'. These choices can be based on any header or URI path > component or query param, as well as many of the 'request state' values > available (user id, name, database etc.). > > > > If your using a REST server which is created by the REST APIS' s then you > will need to modify the generated rewriter - carefully - so as not to break > the existing REST library infrastructure. > > > > > > > > > ----------------------------------------------------------------------------- > > David Lee > Lead Engineer > *Mark**Logic* Corporation > d...@marklogic.com > Phone: +1 812-482-5224 > > Cell: +1 812-630-7622 > www.marklogic.com > > > > *From:* general-boun...@developer.marklogic.com [mailto: > general-boun...@developer.marklogic.com] *On Behalf Of *David Ennis > *Sent:* Thursday, May 07, 2015 1:40 PM > *To:* MarkLogic Developer Discussion > *Subject:* Re: [MarkLogic Dev General] external auth > > > > HI. > > > > This type of scenario seems very possible with the Enhanced HTTP erver > configuration options available in Version 8. One of the most obvious > out-of-the-box benefits of the new server rewrite engine is the fact that > you need not have a separate port for your web app and REST API, for > example. Consider also that you have control over quite a bit - including > switching module databases and content databases as part of the rewrite > rules - which may be of benefit to you for what you describe. > > > > http://developer.marklogic.com/features/enhanced-http > > > > > > > > > > > > > > > Kind Regards, > > David Ennis > > > > > > *David Ennis* > *Content Engineer* > > [image: HintTech] <http://www.hinttech.com/> > Mastering the value of content > creative | technology | content > > Delftechpark 37i > 2628 XJ Delft > The Netherlands > T: +31 88 268 25 00 > M: +31 63 091 72 80 > > [image: http://www.hinttech.com] <http://www.hinttech.com/> [image: > http://www.hinttech.com/signature/Twitter_HintTech.png] > <https://twitter.com/HintTech> [image: > http://www.hinttech.com/signature/Facebook_HintTech.png] > <http://www.facebook.com/HintTech> [image: > http://www.hinttech.com/signature/Linkedin_HintTech.png] > <http://www.linkedin.com/company/HintTech> > > > > On 7 May 2015 at 17:28, cyanline llc <i...@cyanline.com> wrote: > > Hello, > Looking for a bit of philosophical help here. We're deploying > rest-apps with Roxy to one site. We have built a second site where users > register, login, and perform a number of actions. Then, when the user is > ready to use the marklogic rest-app, we pass them from the second site > to the marklogic site. > We would like that the user need not authenticate themselves again > *and* that a user only has access to their rest-app, but not the others. > With this current setup, we can see that we either need to pass the > session data from one server to another, or have a third-party server > track and share session data with the other 2 servers (ie ldap). > Is ldap the way to go or are we way off with this current setup/there > is a better way to do this? > > Thank you > > _______________________________________________ > General mailing list > General@developer.marklogic.com > Manage your subscription at: > http://developer.marklogic.com/mailman/listinfo/general > > > > _______________________________________________ > General mailing list > General@developer.marklogic.com > Manage your subscription at: > http://developer.marklogic.com/mailman/listinfo/general > >
_______________________________________________ General mailing list General@developer.marklogic.com Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
