I'll try testing this later, the documentation here says that an RQL request
should return details about which sessions are logged in for that specific
user for CMS versions 6 and above.
On Wed, Dec 16, 2009 at 8:38 AM, TonyGayter <tonygay...@googlemail.com>wrote:
> Yeah, both the session and rql services just send back the 101
> error :'(
>
> All Im asking reddot to do is what it says on the tin... I think Im
> probobly asking to much lol
>
>
> On Dec 16, 2:34 pm, Kenley Capps <kenleyca...@gmail.com> wrote:
> > Have you tried simply sending the equivalent RQL over the webservices?
> The
> > RQL response sends back quite a bit of info.
> >
> > On Wed, Dec 16, 2009 at 8:24 AM, TonyGayter <tonygay...@googlemail.com
> >wrote:
> >
> >
> >
> > > Thanks for the reply, This does seem to be the simplest solution (kind
> > > of) however it assumes the ability to have a free admin license to log
> > > in with. I cant guarantee the availability of multiple admin licenses
> > > to be able to do this (each session takes up 1). For example, if a
> > > client has purchased 2 admin licenses and one is locked to my user,
> > > and another to the admin of the site. How would I be able to log my
> > > user off and back on (or indeed just get the login id ans session id)?
> > > Using this method I would be stuck.
> >
> > > In the manual it says if the user account is locked out it should send
> > > the users details (login guid etc) in the response, which it does in
> > > certain circumstances (I can see the response I want in the common
> > > log). If this response was return correctly via web services there
> > > would be no problem at all.
> >
> > > It seems the web services have just been thrown together with no
> > > regards to what should actually be returned!! I cant believe this
> > > fundamental function does not work correctly. Its driving me crazy.
> >
> > > On Dec 16, 2:05 pm, Kenley Capps <kenleyca...@gmail.com> wrote:
> > > > Ack! Terribly sorry for the double post! This google group has been
> > > acting
> > > > very strangely for me, and Thunderbird decided to go ahead and send
> my
> > > email
> > > > out instead of saving as a draft! :)On Wed, Dec 16, 2009 at 8:02 AM,
> > > Kenley Capps <kenleyca...@gmail.com> wrote:
> > > > > Finally! My messages are going through! OK.
> >
> > > > > First off, let me preface that I currently use the webservices (for
> > > > > flexibility.) If you're using a page in SmartEdit or just a
> standalone
> > > page
> > > > > on the server, you can still make use of RQL to achieve the same
> thing.
> >
> > > > > LOGGING IN (WEBSERVICES)
> > > > > The guid is passed back as the response from the webservice, if
> > > successful.
> > > > > I'll use a .NET example (assuming you've added the webservice to
> your
> > > > > solution):
> >
> > > > > if (service == null)
> > > > > {
> > > > > service = new
> > > > > YourCompany.RedDot.CMS.RQL.SessionService.SessionService();
> > > > > service.Timeout = SERVICE_TIMEOUT;
> > > > > }
> >
> > > > > guid = service.Login(username, password);
> > > > > Console.WriteLine("Successful login with loginid
> {0}",
> > > > > guid);
> >
> > > > > LOGGING IN (RQL)
> > > > > The guid is passed back along with some information when you send
> the
> > > > > proper request:
> >
> > > > > Login Request:
> > > > > <IODATA>
> > > > > <ADMINISTRATION action="*login*" name="*admin*"
> > > password="*password*"/>
> > > > > </IODATA>
> >
> > > > > Example response:
> > > > > <IODATA>
> > > > > <LOGIN guid="*[!guid_login!]*" server="*MyServer*"
> > > > > serverguid="*[!guid_server!]*" userkey="*[!key_user!]*"
> > > > > usertoken="*[!key_token!]*"/>
> > > > > <USER guid="*[!guid_user!]*" name="*admin*" fullname="*Admin*"
> > > id="*1*"
> > > > > flags1="*0*" flags2="*32768*" dialoglanguageid="*ENU*"
> > > > > dialogtextdirection="" languageid="*ENU*" showstarthelp="*0*"
> > > lcid="*
> > > > > 1031*"
> > > > > navigationtype="*0*" preferrededitor="*0*"
> invertdirectedit="*0*">
> > > > > <MODULES>
> > > > > <MODULE guid="*[!guid_module!]*" id="*cms*" name="*0*">
> > > > > <MODULES>
> > > > > <MODULE guid="*[!guid_module!]*" id="*smarttree*"
> > > name="*13769*
> > > > > "/>
> > > > > ...
> > > > > </MODULES>
> > > > > </MODULE>
> > > > > <MODULE guid="*[!guid_module!]*" id="*ccs*" name="*0*"
> > > repository="*
> > > > > xcms1*">
> > > > > <MODULES>
> > > > > <MODULE guid="*[!guid_module!]*" id="*dms*"
> name="*13774*"/>
> > > > > ...
> > > > > </MODULES>
> > > > > </MODULE>
> > > > > ...
> > > > > </MODULES>
> > > > > <LASTMODULES>
> > > > > <MODULE project="*[!guid_project!]*" projectname="*Project
> name*"
> > > > > id="*smarttree*" guid="*[!guid_module!]*"
> lastid="*smarttree*"
> > > > > lastguid="*[!guid_!]*" last="*0*"/>
> > > > > ...
> > > > > </LASTMODULES>
> > > > > </USER>
> > > > > </IODATA>
> > > > > You're looking specifically for the value of guid attribute from
> that
> > > > > response.
> >
> > > > > OK. We've got our login guid. However, if our app ever crashes or
> > > leaves a
> > > > > session hanging, then we need to be able to log that stale session
> off!
> > > > > Unfortunately the only way to accomplish this is to increase the
> number
> > > of
> > > > > allowed concurrent sessions to 2 or more for the "RQL" user, so it
> can
> > > login
> > > > > and logoff the other concurrent sessions. Otherwise, you'll just
> > > receive an
> > > > > error back (from the webservices it says RDE101 if I recall
> correctly.)
> >
> > > > > So in order to do this, we have to perform the following (after
> logging
> > > > > in):
> > > > > 1. Get a list of all online users
> > > > > 2. Loop through and find the one that has the same username as you
> > > > > 3. Log that session off
> >
> > > > > STEP 1: List all online users:
> > > > > <IODATA loginguid="*[!guid_login!]*">
> > > > > <ADMINISTRATION>
> > > > > <USERS action="*connectlist*"/>
> > > > > </ADMINISTRATION>
> > > > > </IODATA>
> >
> > > > > Example response:
> > > > > <IODATA>
> > > > > <USERS>
> > > > > <USER guid="*[!guid_user!]*" id="*1*" name="*name*"
> > > > > fullname="*First name Last name*" flags1="*0*" flags2="*0*"
> > > > > email="*n...@company.com*" maxlevel="*1*"
> > > dialoglanguageid="*ENU*"
> > > > > loginguid="*[!guid_login!]*" logindate="*37551,3837384259*"/>
> > > > > moduleid="*servermanager*" intern="*0*"
> > > > > moduledescription="*Server Manager*"
> projectname="*Up-And-Away*"
> > > > > projectguid="*[!guid_project!]*"/>
> > > > > ...
> > > > > </USERS>
> > > > > </IODATA>
> >
> > > > > Note that you can specify a specific userguid element on the
> request to
> > > > > list all online users to retrieve only the concurrent sessions for
> that
> > > > > user. However, since we don't necessarily have the guid of the
> current
> > > user
> > > > > (if we used the webservices), then we'll just list all online users
> and
> > > look
> > > > > for our specific ones.
> >
> > > > > STEP 2: Loop through all users in that result set, and find the one
> > > that
> > > > > matches your username
> > > > > I use the following process (actual snippet from a .NET wrapper
> I've
> > > worked
> > > > > on):
> >
> > > > > // In the Session class
> > > > > List<User> users = User.ListOnline();
> > > > > foreach(User sessionUser in users)
> > > > > {
> > > > > if (sessionUser.Name == username)
> > > > > {
> > > > > if (sessionUser.LoginGuid == guid)
> > > > > {
> > > > > this.user = sessionUser;
> > > > > }
> > > > > else if (logoutConcurrentInstances)
> > > > > {
> > > > > Logout(sessionUser);
> > > > > }
> > > > > }
> > > > > }
> >
> > > > > As you can see, if you find the user with your name and your
> loginguid,
> > > > > that's you. Otherwise, if you have opted into logging out
> concurrent
> > > > > instances, log that user out (since they have the same username,
> but
> > > not the
> > > > > same login guid)
> >
> > > > > Finally,
> > > > > STEP 3: Logout user
> > > > > This one is pretty basic.
> >
> > > > > LOGGING OUT (Webservices):
> >
> > > > > Following the snippet from logging in via webservices, logging out
> is
> > > > > incredibly simple:
> > > > > service.Logout(guid);
> >
> > > > > LOGGING OUT (RQL):
> >
> > > > > Request:
> > > > > <IODATA loginguid="*[!guid_login!]*">
> > > > > <ADMINISTRATION>
> > > > > <LOGOUT guid="*[!guid_login!]*"/>
> > > > > </ADMINISTRATION>
> > > > > </IODATA>
> >
> > > > > Response:
> > > > > <IODATA>
> > > > > </IODATA>
> >
> > > > > And you're done! I hope this was helpful.
> >
> > > > > On 12/16/09 2:50 AM, TonyGayter wrote:
> >
> > > > > Also th euser woul dprobobly be an admin, many of our clients only
> > > > > have 2-3 admin logins, Im assuming each session woul duse up an
> admin
> > > > > license which woul dcause uproar.
> >
> > > > > On Dec 16, 8:48 am, TonyGayter <tonygay...@googlemail.com> <
> > > tonygay...@googlemail.com> wrote:
> >
> > > > > If you have some code for this action that would be great, Im
> banging
> > > > > my head against a brick wall with reddot at the moment.
> >
> > > > > Increasing the number of allowed sessions isnt really the best way
> to
> > > > > tackle the issue, for example, what happens if I write an admin
> tool
> > > > > and the pc crashes out a few times (leaving the user logged in) it
> > > > > could still hit the session limit.
> >
> > > > > On Dec 14, 4:41 pm, Kenley Capps <kenleyca...@gmail.com> <
> > > kenleyca...@gmail.com> wrote:
> >
> > > > > I've been having issues with replying to the google groups. If
> this
> > > goes
> > > > > through, I have the code to do it and will provide (I also created
> a
> > > > > .NET wrapper mostly because I needed a lot more than RustyLogic's
> > > provided.)
> >
> > > > > On 12/14/09 10:35 AM, TonyGayter wrote:
> >
> > > > > Hmmm, I had forgotton that, Surely they store it somewhere
> > > though?
> > > > > This is goin got drive me nuts.
> >
> > > > > On Dec 14, 4:29 pm, "Killingsworth, Chad
> > > A"<chadkillingswo...@missouristate.edu>
> > > <chadkillingswo...@missouristate.edu> wrote:
> >
> > > > > Login GUIDS and Session GUIDs are stored in ASP Session
> > > variables.
> >
> > > > > Now for the fun part where you realize that since ASP.Net
> and
> > > ASP do not share the same session objects - you have a tricky problem.
> >
> > > > > Chad Killingsworth
> > > > > Assistant Director of Web& New Media
> > > > > Missouri State University
> >
> > > > > -----Original Message-----
> > > > > From:
> >
> > ...
> >
> > read more ยป
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "RedDot CMS Users" group.
> To post to this group, send email to reddot-cms-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> reddot-cms-users+unsubscr...@googlegroups.com<reddot-cms-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/reddot-cms-users?hl=en.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"RedDot CMS Users" group.
To post to this group, send email to reddot-cms-us...@googlegroups.com.
To unsubscribe from this group, send email to
reddot-cms-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/reddot-cms-users?hl=en.
