11.6.3 I want to make an example login with webspeed and wonder what people do now to keep track of username and password? I would think I need a session table and have a sessionID as a parameter/hidden element passed between server and user. Could anyone share some examples of what would be a good and safe solution? I also wonder how to keep track of change of fields within a dbtable, to see if there has been changes to a record while been at the client. I can't remember clearly what I did earlier on that topic. //Geir Otto
I want to make an example login with webspeed and wonder what people do now to keep track of username and password? I would think I need a session table and have a sessionID as a parameter/hidden element passed between server and user. Could anyone share some examples of what would be a good and safe solution?
I also wonder how to keep track of change of fields within a dbtable, to see if there has been changes to a record while been at the client. I can't remember clearly what I did earlier on that topic.
Classic WebSpeed, but I see I need to do some more reading about the PASOE :-)
You would be much better off using PASOE.
In Classic Webspeed, the problem is not just the login, but to know what user is running the application programs. For this, I used the solution to keep a randomic identifier into a login table related to the user authenticated.
Remember that stateless means the webspeed agent can run programas from many users, so you have to test this information in every hint.
I use classic WebSpeed, as we're not yet on 11.6 - and, frankly, because I have all the plumbing working and stable for Classic WebSpeed and hadn't had the time to try to rewrite it for Tomcat...
When a user logs in, I generate a unique session id, which I store in a table together with the user's internal identifier, the remote-address, a last contact time and some other stuff. This session id is stored in a cookie in the browser and sent with every request, together with some other hashed data. If all the hashed data plus sessionId plus remote-address pan out right, I know who the user is, and can check whether s/he is allowed to make the request. If not it ends right there. Otherwise the request gets executed in the actual application.
I have triggers on every table to ensure data-integrity. There, I also up an internal version field, so I can always check before the update if the record has changed since it was originally retrieved for the update. Triggers may also store change-data (for auditing or reconstructing data at a particular date), if that feature is turned on for a particular table.
Re Mike's comment: I haven't used mapped objects in more than a decade. I don't think anybody would at this time consider building a web-app where the front-end (JS/HTML) is not completely separated from the backend (ABL). Classic WebSpeed works very well in such an architecture - for example with JQuery and other ajax based frameworks...
I don't even have my backend tied to WebSpeed! It is implemented in a strictly front-end independent, simple batch program way. That way, I can run it from a test-wrapper in the editor, which makes debugging a heck-of-a-lot easier... But that goes beyond the original question...
I haven't read about Pacific yet, but it sounds like adding a lot of complication (and state awareness) to users using web enabled applications.
Adrino's point is why some have gone to webspeed - statelessness. That way one doesn't have a bunch of processes twiddling their thumbs while waiting for the user to come back to them.
These days I don't like complication. Especially if the login ids are on another system and administered from there.
State aware web apps - about as useful as html-mapping.
Hopefully Pacific doesn't promote state aware and having to id the user on it's own infrastructure.
Scott, it isn't that PASOE advocates statefulness, what it does is make it inexpensive to use statefullness when it makes sense, e.g., a complex query which is being paged. One can and should use statelessness with PASOE for all the usual traffic, but, when statelessness is making things more expensive, then statefullness is an option.
Thanks for the clarification - like I said, I haven't read the docs yet.
Ok, so if I want to do the basic thing, I would continue do what I did as in the beginning of WebSpeed, by using a sessionid that I sent using hidden-field,cookie or URLfields.... When it comes to changes in the table, I will need to do a comperans of the record after returning back from the client. Hopefully PASOE has a affordable price so that I can start using that :-) I think the Sping Security seems nice..
Thanks Marian, I would like to have a demo. I will get in contact in Noordwijk.