tag:blogger.com,1999:blog-1527573980897631948.post1366235863546825531..comments2023-06-14T12:59:52.209+01:00Comments on DominoYesMaybe: Log In into Domino using AJAXAnonymoushttp://www.blogger.com/profile/09211785785682223613noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-1527573980897631948.post-3443309900816468732008-03-06T10:24:00.000+00:002008-03-06T10:24:00.000+00:00@JakeThats something we are doing at the minute .....@Jake<BR/><BR/>Thats something we are doing at the minute ... I have a function that is called as part of the post connection event that tests for the continued existence and contents of the DomAuthSessId cookie, which if your session expires on the server will disappear, if this happens the user is pushed back to the logon screen.<BR/><BR/>In my app the login is a [div] near the top of the page, like the blogger log in. Once logged in the [div] is set to display:none; and a logout option appears as does the "logged in" all without the page having to be re-composited by the server.<BR/><BR/>This was more a "look and feel" tip<BR/>i really am not keen on the amount of fiddling you have to do to get a nice consistent signon display for an app.<BR/><BR/>1. The look of the login page is application dependent and not server dependent.<BR/><BR/>2. When the page expires and the user is forced to re-logon you can do that without moving from their current position in the app. Simply hide the current data panels and display the logon, and when the user logs back in redisplay them as they were. I know the server does this too.. but it looks so.. OLD :)<BR/><BR/>3. When you send a notification mail say of a review pending and the link points at a specfic document you can code your page to do the logon (dependant on the existence of DomAuthSessId) and then display the document. I know the server does this anyway but you get again a consistent UI feel to the application.<BR/><BR/>4. I have the JSON I mentioned earlier returning a Logged On User Object. Which gives me the bits of the PAB for that user that I might need, which the server doesn't do on logon.<BR/><BR/>None of these are show-stoppers and the server does most of the things for you anyway.<BR/><BR/>My app follows this scheme on logon<BR/><BR/>01. Nicely formated home page, admin contact details etc and a logon option<BR/><BR/>02. User logs on (sucessfully)<BR/><BR/>03. Page polls the server and gets back the users available menu options based on user name<BR/><BR/>04. Menu system enabled and displayed<BR/><BR/>05. User free to do whatever they need to.<BR/><BR/>I did some benchmarks to see if this was was any more efficient at compositing the page than the tradition method.. and is was about the same the AJAX method was slightly faster bit only marginally so on a normal menu tree.<BR/><BR/>SteveAnonymoushttps://www.blogger.com/profile/09211785785682223613noreply@blogger.comtag:blogger.com,1999:blog-1527573980897631948.post-32482418927841048192008-03-06T09:46:00.000+00:002008-03-06T09:46:00.000+00:00Alternatively you could test the cookies of the re...Alternatively you could test the cookies of the returned page for DomAuthSessId <BR/>I've been thinking about it and wondering it it's worth logging in with Ajax? Surely upon a successful login you'd want to refresh the whole page anyway as so much of what makes up most webpages is user dependent. No?<BR/>JakeAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-1527573980897631948.post-87851602168142532772008-03-06T09:11:00.000+00:002008-03-06T09:11:00.000+00:00@raduYou are corrent and iIn the application I use...@radu<BR/><BR/>You are corrent and i<BR/>In the application I uses a POST rather than a GET for this very reason while not perfect it is as Jake says doing exactly the same (with a POST) as the server does The Application is not on a public facing port it is an intranet only app and yes it I direct the logon to an SSL port. I was going to cover these points if anyone was interested ... LOL ... perhaps I should have straight away .. I have added an update to the orginal post.<BR/><BR/>@Jake<BR/><BR/>Acutally I am looking at the JSON return today. I was going to load up PAB info about the signed on user.. DEPT, MANAGER, FULLNAME etc into a JSON User object rather than have to bounce back and forth to the server everytime we need that info.<BR/><BR/>SteveAnonymoushttps://www.blogger.com/profile/09211785785682223613noreply@blogger.comtag:blogger.com,1999:blog-1527573980897631948.post-61133150091668135562008-03-06T08:10:00.000+00:002008-03-06T08:10:00.000+00:00This is a topic I've been meaning to tackle for a ...This is a topic I've been meaning to tackle for a while and probably will do soon.<BR/><BR/>I don't see it as a security issue, as long as you user POST rather than GET. In that way you're just doing exactly what a normal Domino login form does.<BR/><BR/>Why not have it return json? All the agent/page/whatever needs to do is return "@UserName" and see if it's "anonymous" or not.<BR/><BR/>JakeAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-1527573980897631948.post-5647215286529855082008-03-06T05:55:00.000+00:002008-03-06T05:55:00.000+00:00from the security point of view this is hell, sinc...from the security point of view this is hell, since all your usernames AND passwords will appear in the logs of the Domino server in clear text. I would advise against it, hope your app is not on public site :)Radu Cadariuhttps://www.blogger.com/profile/00935199731236759396noreply@blogger.com