wprins

You can monitor the number of active sessions and auto-restart when no-one is on. You would then have to build some kind of notification mechanism into your system to allow you to tell your service to restart, or that allows it to notice when a new release has been made. Further, if you're using a standalone service .exe then you should be able to rename the .exe file while the service is running to put the new build .exe in place prior to this. So basically, you can try: 1) Rename existing service.exe to service.exe.old (or whatever) 2) Notify running service to restart. 3) It monitors sessions and then restarts itself with CreateProcess() or whatever. (I can probably provide concrete example if needed.)

Thanks for the prompt response, very helpful. I'll look into this.

Is it possible to set the font colour of the font used for TUniTabSheets? (I've tried setting the Font.Color property both at design and runtime and it doesn't seem to affect anything? Customer is asking for tab colorization on certain conditions...)

Really, you need to rethink the design of your interface/UI. Decompose into frames and/or dynamically create as needed I think. You can probably use an approach similar to that used in the Demo "mdemo" application.

Something like this perhaps. Add the following to your UniServerModule (and set the HTTPCommand event handler to the below event handler code) to intercept the HTTP request and deny access if not 127.0.0.1. Note: The UserHostAddress() is not neccesary here for checking 127.0.0.1. I include it however for interest sake, in the hope that it's instructive, since in the more general case where you want to implement IP Whitelisting and are running behind a reverse proxy server, you would then need to obtain the remote client's IP address (as opposed to the reverse proxy server's IP, which would otherwise always appear to be the immediate "client"/"RemoteIP".) Hope that makes sense. function StrIsEmpty(const AInput: string) : boolean; begin Result := Length(Trim(AInput)) = 0; end; function StrIsFull(const AInput: string): boolean; begin Result := not StrIsEmpty(AInput); end; function UserHostAddress(const ARequest: TIdHTTPRequestInfo): string; // Modified from http://edn.embarcadero.com/article/40890 // to use Indy TIdHTTPRequestInfo as opposed to WebBroker request object. // **Modifications not fully tested yet.** // This is intended to be useful in contexts where UniGUI/Indy server // may be accessed via reverse proxy and the actual remote user address // (as opposed to the proxy's host address) is desired to be checked // against. var lStr: string; lParts: TStringDynArray; lIndex: Integer; begin lStr := String(ARequest.CustomHeaders.Values['x-forwarded-for']); if StrIsFull(lStr) then begin lParts := SplitString(lStr, ','); lIndex := High(lParts); while ((lIndex >= Low(lParts)) and (StrIsEmpty(lParts[lIndex]))) do Dec(lIndex); Result := String(lParts[lIndex]); end else Result := String(ARequest.RemoteIP); if Pos(':', Result) > 0 then Result := Copy(Result, 1, Pos(':', Result)-1); end; procedure TUniServerModule.UniGUIServerModuleHTTPCommand( ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo; var Handled: Boolean); var UserHostIP : string; begin UserHostIP := UserHostAddress(ARequestInfo); if not (UserHostIP = '127.0.0.1') then begin AResponseInfo.ResponseNo := 403; AResponseInfo.ResponseText := 'Access denied.'; AResponseInfo.ContentType := 'text/plain'; AResponseInfo.ContentText := 'Access denied. Access only allowed from 127.0.0.1.'; // Of course you could also emit 401 and demand some other auth here. Handled := True; end end; Hope that helps.

Yes. You should do authorization of upload requests via some mechanism. HTTP supports some inbuilt mechanisms. "Basic" authentication means user+password must be passed with the request. This is obviously a bad way of working when using http, though it is somewhat mitigated by using SSL, though in theory a proxy-in-the-middle attack with suitable fake certificates (or a suitably compromised browser) could in theory be used to steal the password. To prevent at least sending the password over the wire you can in general therefore use "Digest" authentication (https://tools.ietf.org/html/rfc2617) instead. (Don't know/haven't checked whether UniGUI supports this or not, though I assume it should be possible one way or another...) Other approaches include issuing/using access tokens (some random key) that is passed with the requests, where you associate the token with a user's account and can then monitor token usage for abuse and expire them as needed. (See [1], "Persistent authentication Tokens".) As an aside: The current "remember me" demo application is in this respect really bad currently, as it stores the user/pass in cookies on the browser that can be easily read/stolen. Ideally it should be improved to (at least) use the access-token approach outlined above, or to at least not use the actual password but a digest/hash instead and store this encrypted. I was thinking of improving it. Would it be an ideal to publish the demo applications on Github (or perhaps on BitBucket as a private repo with explicit invites if making it public is not agreeable) so that we can make improvements? I include some relevant links from my bookmarks for the benefit of readers: References [1] https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#title.2 [2] https://pdos.csail.mit.edu/papers/webauth:sec10.pdf [3] http://martinfowler.com/articles/web-security-basics.html#HashAndSaltYourUsersPasswords [4] https://crackstation.net/hashing-security.htm [5] http://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication#477579 [6] http://stackoverflow.com/questions/244882/what-is-the-best-way-to-implement-remember-me-for-a-website [7] http://jaspan.com/improved_persistent_login_cookie_best_practice [8] http://security.stackexchange.com/questions/64984/remember-me-cookies-did-i-implement-them-securely [9] http://security.stackexchange.com/questions/44/how-to-securely-implement-a-remember-me-feature [10] https://www.troyhunt.com/how-to-build-and-how-not-to-build/

I have now updated everything (latest builds of everything everywhere) and redeployed the test server and everything seems to show up as expected. So never mind!

You can only view the params in HTTPAnalyzer as it works with your browser. E.g. the data is otherwise protected/encrypted end-to-end over the wire (browser to server.) What are you trying to do?

Thanks - I've updated my emali address. Also, I've installed the latest themepack, and the uni_* themes now show up as expected, but for some reason the others (default, blue, gray, neptune) are missing? (The runtime and themes I installed on the test server is a slightly newer build than the one currently still on my dev machine, not sure if that might have something to do with this?)

Hi, I have installed the runtime package on our (test) server, however only the default three themes are available. Where and how is one supposed to deploy the additional themes? (I've also not found any reference to this in the documentation.) Thanks.

Which Rest components? (Delphi's? Generally it's best to assume that nothing is thread safe unless explicitly stated.)

Hi Apologies for what might be a beginner question, but is there an obvious/easy/trivial way to respond to the runtime resizing of the client side browser and consequently anchored (or aligned) DBGrid, so that the page size used by the DBGrid matches the visible size in the browser? Thanks.

Right, noob error then! Thanks.

(Thanks for the rapid response.)

Demo project posted here: http://www.filedropper.com/project1_8 (How do you directly attach to posts? There is the "My Media" button when posting but I was unable to quickly locate where/how to upload to the mentioned "Your Media Library".)

Hi, I've tried to create a mobile version of the proof of concept desktop application I've created. I did this by creating first of all a mobile application with the wizard, and then adding the frames (from the desktop version) as well as all needed code/dependencies into the mobile application. Then I replaced the server module and session module (main module) generated by the wizard, with those defined in the desktop application (remove and add the ones from the other project.) Lastly I wired up the frames (login and main frame) onto the corresponding mobile forms and then rejigging them to be positioned reasonably. The project then compiled and ran fine. However when attempting to use it, I get in my browser the following errors 1) First of all an alert dialog displaying "Cannot read property Panel of undefined" 2) When dismissing this I then get a (nicely animated) dialog displaying: Ajax Error O44 is not defined I'm completely at a loss as to what might be causing this. Has anybody seen it? Have I done something wrong or broken something inadvertently? Many thanks. Edit: I've just created another blank mobile app with nothing in it but: a) MainForm b.) LoginForm c) LoginFrame with edit and button added d) Login Frame dropped on Login form e) Compile, Run. Result: Alert saying "Cannot read property 'Text" of undefined." So I suppose this must be yet another trial limitation or bug? (Can I just tactfully say that the trial limitations are making it quite difficult for me to try and develop something sufficiently compelling to get agreement from customers, nor is it helping convince me that the quality/stability is there to risk taking to production...)

I'm trying to change the theme using the combobox in the mdemo but it doesn't seem to do anything. Is this because I'm using the trial edition?

Hi. I'm trying to change the default port from 8077 to something else. I'm trying to do this in the ServerModuleCreate event method by assigning to the Port property, but it is being ignored. Is this a bug? (I'm running the trial edition still.)

Yes I am. Thanks for responding.

Hi, I've noticed on my test apps the TUniForm/TUniLoginForm .Caption property value is not being displayed at runtime. Instead the forms are displaying the form name. Is this a bug or am I missing something? Thanks.

Thanks I'll have a look.

Not wanting to nit pick, but I think some warning and/or improvement may be in order in the LoginForm Cookie demo. The demo directly stores the username and password in plaintext cookies. This is not good practice and should not be encouraged via example. For more see: https://www.troyhunt.com/how-to-build-and-how-not-to-build/ http://security.stackexchange.com/questions/64984/remember-me-cookies-did-i-implement-them-securely http://security.stackexchange.com/questions/44/how-to-securely-implement-a-remember-me-feature Edit: Also: https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#title.2 (Would it be possible to host the demo's on e.g. a github repository? I'd guess lots of people would be happy to submit pull requests for fixes and improvements to the demo applications?)

So I suppose the thundering silence implies everyone runs their UniGUI apps with the browser fully visible(?)

Thank you!

Hi, I'm trying out the mdemo and am having timeouts every so often (3 minutes or so it seems) with the server raising the following exception: --------------------------- Debugger Exception Notification --------------------------- Project mdemo.exe raised exception class EUniSessionException with message 'Invalid session or session Timeout.'. --------------------------- Break Continue Help --------------------------- Is this because this is the trial edition, or is there something wrong? Thanks Walter