Jump to content


uniGUI Subscriber
  • Posts

  • Joined

  • Last visited

  • Days Won


Norm last won the day on May 25 2020

Norm had the most liked content!

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Norm's Achievements


Member (2/4)



  1. In case somebody else strikes this problem.... It turns out this was a Windows (ISAPI) issue. Restarting the server fixed it.
  2. It appears applications started through HyperServer do not obey the UniServerModule -> Options -> soRestartSessionOnTimeout setting. e.g. uniGUIApplication.UniSession.Terminate() always starts a new session even when soRestartSessionOnTimeout is set to false. The same happens on SessionTimeout expiry. The same application works as expected when started directly i.e. no Hyperserver. Can you please verify and suggest a workaround if possible.
  3. Rodrigo, In the $(document).ready() function, replace the form.submit event with an click event and it will work for both mobile & desktop. See below. $(document).ready(function() { var form = $("#payment_form") form.submit(function(event) { // Remove this $("#btn_finally").click(function(event){ //Replace with this event.preventDefault(); ... ... }) });
  4. Hey 55143681, Would you mind explaining why you would want to do that. For an application like uniGui I think you would be punishing your users by not using the cache.
  5. Hi Roberto, Recording user logins in the database and deleting the record when they logout is standard practice. However in order for this strategy to work well you also need to monitor user activity and kill sessions (trigger a logoff event) that are idle for too long. This would include those who have left their browser idling too long as well as those whose PC has gone off-line for whatever reason. There are several examples in this stream about how other developers monitor and shut down idle sessions. Just out of interest, what do you do if someone tries to log in with an ID that is already logged in?
  6. Hi Irigsoft, Thank you for sharing your ended session procedure. It will save me a lot of time. Interesting regarding your session timeout monitoring strategy. I do more or less the same thing, i.e. server-side timer starts after successful login and session runs forever as long as I hear from the user periodically. What I do differently is this: - I have a timer running on the client-side that monitors keyboard & mouse activity. As long as there is activity the client-side timer sends a ping to the sever every 2 minutes. If there is no activity for 15minutes the ping stops. - Every ping from the client restarts the timeout count on the server side. - If server-side timer expires I trigger a client-side “Submit & Logout” function (the project is a time-sheet recording system and I don’t want the user to lose any information they have entered and not yet submitted). If there is no unsaved data the procedure will simply send a logout request. - If I don’t hear from the client within 2 seconds of this I force a logout procedure (free resources etc.) and display the login screen. The problem I’ve had so far (that is what started this topic) was what to do with cases where I display a login screen and the user never responds. Now that I know about the user-defined expired-session procedure (thanks Sherzod) I monitor the session timeout event and let the session expire if the user does not respond within 5minutes. This is the only case where I use the session timeout (i.e. login timeout).
  7. Sherzod, Thank you for pointing this out. It is not something I was aware of and it looks very promising. I will investigate and come back with some feedback.
  8. Sherzod, Thank you for responding so promptly. I am familiar with the options you mentioned and I use SessionTimeout extensively. As for RestartSessionOnTimeout, I never use it because I think it is bad practice for the following reasons: - Like all respectable web portals I monitor user idle-time and forcibly log the user out after displaying a warning if threshold is exceeded. RestartSessionOnTimeout would make this standard-practice behavior redundant. - RestartSessionOnTimeout is a bad use of resources, especially for mobile devices (which applies in my case). Imagine having to keep dozens of sessions alive when their users are walking around with their phones in their pockets. I think sessions should be allowed to expire for the sake of security and resource optimization, but uniGui should let developer decide how to handle resulting issues, in the same way as Delphi lets us to handle exceptions. I think the message "Invalid session or session Timeout..." is a blunt tool that is very unfortunate and a bit embarrassing. It seems uniGui is the only framework that has this issue. Other frameworks provide the option to redirect to an Expire Session page. As an alternative can I suggest a new so option that will start a new session if the http session does not exist. I would be interested to know what fellow uniGue developers think.
  9. When a user accesses a site and a login form is shown, the session expiry countdown starts immediately. This means the session can expire without the user having logged in. If the user subsequently submits a login request the ugly "Invalid session or session Timeout..." message is displayed on the users browser. The message looks specially awful on mobile devices and hints at immature (un-robust?) web design. Is there any way one can intercept this default http handling and instead automatically start a new session and re-display the login screen, maybe with an optional "expired session" flag so an appropriate message can be displayed to the user? I am having this issue especially with mobile-phone users who, at the end of a their visit, log out and put the phone away without closing the browser. This means the login screen can remain displayed for many hours until the next time they attempt to log in. Any suggestion on how to handle this?
  10. You need to catch it in the MainModule: procedure TUniMainModule.UniGUIMainModuleHandleRequest(ASession: TObject; var Handled: Boolean); var Event : string; begin if (ASession<>nil) then begin if TUniGUISession(ASession).IsAjax then begin try Event:= TUniGUISession(ASession).ARequest.Params.Values['evt']; if (Event = 'bclose') then //Do something.. except end; end; end; end;
  11. Hayri, Thank you very much for this work-around. It is not an ideal solution but I can live with it. 2 questions please: - Will the underlying issue be fixed in a future update? - Can you give me access to more detailed documentation re the JSCallGlobal method so I can try to optimize your suggested solution.
  12. The alert should fire every time you resize the browser page. Have a look at my opening argument. The sample project I suppled has 2 forms (Page 1 & Page 2). Page 1 uses TUniLoginForm, page 2 uses TUniForm. On page 1 the alert only fires when you open the form. On page 2 it fires every time you resize the browser. You get to page 2 by clicking on the login button.
  13. Johan, https only works with port 443. If you try to use 440 it will revert to http and the user will be warned that it is an un-safe site. There are only 2 possible ways to use https for multiple sites on the same machine: - Use the ISAPI option with IIS then you can have multiple sites like https://www.mydomain.co.za, https://www.mydomain.co.za/support, https://www.mydomain.co.za/blogs etc. They can all be protected with a single SSL certificate. - Use the sub-domain option. This allows you to have sites like https://www.mydomain.co.za, https://support.mydomain.co.za, https://blogs.mydomain.co.za etc. Registering sub-domains does not cost anything but they would need individual SSL certificates.
  • Create New...