After a little ideas exchange with Angel, I guess that some clarifications about HMGSCRIPT must be done;

1. HMGSCRIPT is a JavaScript library containing a set of functions, that allow us to create web applications, using the same logic as desktop applications.

2. All major web browsers (desktop and mobile) has a JavaScript engine capable of running our HMGSCRIPT apps.

3. HMGSCRIPT is not aimed to create web sites, but web apps.

4. Our application could be in one or more JavaScript (.js) files. These files must be declared in the head section of the html file that will serve as the entry point for our app.

5. The JavaScript code will be automatically loaded, when the user point his browser to our html file serving as our entry-point.

6. Our applications will not have pages. They will have forms (windows) only.

7. Since we will have not pages, will there not page reloads, so, there is no need to use cookies and similar technologies to keep data across server requests.

8. The server requests for data management, are done via AJAX, meaning that the communication works silently in the background, without affecting our GUI.

9. The security scheme is very simple: The user is prompted for an username and password. The data is sent to the server and checked in the users table. If the credentials are ok, the server returns a simple 'OK' to our client app. Then, the username and password are stored in global variables on client. All subsequent requests to the server for data manipulation, will include user credentials, that are checked again in every server data management procedure call, meaning that SERVER PROCEDURES WILL WORK ONLY WHEN VALID USER CREDENTIALS BE SENT WITH EACH REQUEST.

10. In order to enforce security, YOU SHOULD USE CUSTOM SERVER PROCEDURES and not generic ones, since an user with valid credentials, could create a custom client app, to mess with your server, arbitrarily executing data functions like dbquery(), dbdelete(), dbappend() or dbmodify(). THIS IS VALID FOR ANY WEB APP (NOT ONLY HMGSCRIPT ONES). The generic functions mentioned above, must be avoided when security is a concern.

11. Another thing that could be done to enforce security, is to create a 'token' at server login procedure, storing it along the other user data and send it to the client. Then, the client should include it, in all subsequent server procedures calls, along with his username and password, giving an additional security layer. This token should have a limited lifetime.

12. The data management demos are based on Harbour CGI server procedures, but you could use anything you want in the server (ie: PHP+MYSQL). I plan to create a function to make server requests easier, instead of dealing directly with xmlhttprequest, each time, including visual indicators, timeouts handling, etc.

13. I want to keep the library as light and fast as possible, so, I'll try to avoid the incorporation of third party libraries as much as I can, doing only when they do not cause significant impact on performance.

14. Being plain JavaScript, is very likely that HMGSCRIPT work well along other JavaScript libraries of your preference.

Roberto Lopez wrote:
9. The security scheme is very simple: The user is prompted for an username and password. The data is sent to the server and checked in the users table. If the credentials are ok, the server returns a simple 'OK' to our client app. Then, the username and password are stored in global variables on client. All subsequent requests to the server for data manipulation, will include user credentials, that are checked again in every server data management procedure call, meaning that SERVER PROCEDURES WILL WORK ONLY WHEN VALID USER CREDENTIALS BE SENT WITH EACH REQUEST.

10. In order to enforce security, YOU SHOULD USE CUSTOM SERVER PROCEDURES and not generic ones, since an user with valid credentials, could create a custom client app, to mess with your server, arbitrarily executing data functions like dbquery(), dbdelete(), dbappend() or dbmodify(). THIS IS VALID FOR ANY WEB APP (NOT ONLY HMGSCRIPT ONES). The generic functions mentioned above, must be avoided when security is a concern.

11. Another thing that could be done to enforce security, is to create a 'token' at server login procedure, storing it along the other user data and send it to the client. Then, the client should include it, in all subsequent server procedures calls, along with his username and password, giving an additional security layer. This token should have a limited lifetime.

Thanks Roberto! This looks so interesting.
One question about the security 'tokens'.Is it similar to the PhP 'sessions' or are we talking for a completely different thing here? Because using only the user credentials at every request sounds risky to me as you also pointed out. A 'session' oriented system seems much more bulletproof to me.

Roberto Lopez wrote:
Thanks Roberto! This looks so interesting.
One question about the security 'tokens'.Is it similar to the PhP 'sessions' or are we talking for a completely different thing here? Because using only the user credentials at every request sounds risky to me as you also pointed out. A 'session' oriented system seems much more bulletproof to me.

The idea is that the users table should have additional fields for SESION_ID, DATE and TIME.

So, when an user logs in, a random ID is created and saved in the user record, along current date and time.

This ID is sent back to the client as login confirmation. The client stores it in a public variable, visible to all the application.

Then this ID, should be sent along username and password with each further server request.

The ID could expire after a preset elapsed time.

Another (simpler approach) could be use only the SESSIONID for server requests after login (maybe I go with this on future releases).

When the user logs out, or the application is terminated, the variables content will be destroyed.

Consider that the concept of session with HMGSCRIPT, is a little different than with traditional web development, since we have not page reloads on client. Meaning that we can keep variables values on our JavaScript application for all of its 'life'. Server requests (AJAX) will not affect the client state at all.

Regarding, specifically to your question, you could make your harbour server code to emulate PHP's concept of 'session variables', to keep data in the server across requests. In its simplest implementation, you could simply have additional fields in the users table, aimed to store session data.

English by google
Hi Roberto,
I have read carefully your ideas and proposals and I think that you have found the path of development of hmgweb. I think it's best to use a html page input and use javascript to do anything else.
In everything I've read made me remember a framework called backbone.js, I recommend taking a look because I think you can get many ideas from there.
Well, I'm with interest the comments.
Best regards,
Luis Vasquez

Thanks a lot for the clarification Roberto.
I don't know about everyone else but the more i read about this concept of yours the more i get excited.
I looked at the demos you made and i am going to give it a full go during the weekend.

It looks really really promising!A lot of possibilities especially when it reaches the mobile platform full.