SC Security Model: Is it best practice?

Scriptcase 8 Discussion
, ,
#1

The default generated log-in security app basically loads up an multidimensional array per logged in user for all the individual app rights. Looking into View --> Data in Session shows a massive amount of data stored into the servers memory. I can imagine the implications for a large number of logged on users and large number of applications.

Has anyone tried loading up rights in the Init event each time an app is accessed? Would this break the Security functionality? Is there a more efficient way of achieving the objective as opposed to loading such large arrays upfront?

#2

why you care if it will store a lot of data in servers memory?! maximize your resources and let the server take this part off you. playing with security module (unless you know what you are doing) is not really recommended, a lot of things are linked to the functionality of that “data” which is stored and ready to reply user/app requests.

but I recommend is to re-innovate the security module with different kind of password hashing and less errors based on many reviews and feedback of users, but, again, this one is by SC, which is a lost cause :smiley:

#3

The alternative would be to check for rights on each and every action by looking into the database causing a lot of extra database access. Would slow down your application significantly.

#4

Scriptcaser,

You can turn on “Save Session Data in Database” which will do exactly what it says.

This is commonly used when you are load sharing between two web servers that are sharing the same database. When you click on a button at the browser, and you possibly get directed to web server B instead of web server A, the session variables can still be gotten from the database.

The slowdown that you may encounter is virtually unnoticable as long as you have good connectivity between the web server and the sql server.

We use this approach on our web server clusters, and response is great. We also load balance our sql servers so that we have automatic fail over.

Dave

#5

I wanted to know this long time ago :smiley: what other consequences may have? will it make the db bigger size? will those variables be erased when session is timeout or the user logout or close the browser? what you think Dave is it better?

#6

Mike,

I like it very much. If you think about it, the way that session variables are normally kept on a web server, they are stored in a session file. When you access them, they are read into memory. When you update a session variable (write to a ScriptCase global variable) the file is updated. The file lives until session expiration at which time the session file is deleted. How much more overhead can there possibly be if, instead of a file managed by Apache/PHP, the data is stored in a database managed by MySQL? If Apache/PHP and MySQL are running on the same server, many people say that MySQL access of session data is faster than Apache/PHP’s.

So next question would be “how about if the SQL server is on a different machine than the web server”. That is my case. Between servers I have a 100MBit ethernet backchannel, and you absolutely cannot notice any difference in speed, session in database or session in files.

In terms of how long the data lives in the database, the data is deleted upon expiration of the session. That is defined as ‘some configurable period’ without any writes to a session variable. You also can manipulate the session via PHP functions - kill a session, start a new session, etc. But the timeout, say 15 minutes, gets reset every time a session variable (i.e. scriptcase global variable) gets modified. So, if you close your browser without logging out, the session will disappear off the server 15 minutes after the last session variable was written to. Remember, web servers are stateless. They have no idea that you have closed your browser. This is the same as the timeout that you sometimes experience in ScriptCase Development Mode.

In my environment, it is very important to us to have a scalable server farm. If our users go from 2,000 to 20,000 unexpectedly, we need to be able to scale quickly and easily. As a result, MySQL runs on 2 dedicated servers. They are configured for master-master replication so you can access either one and get exactly the same data. Also, either one can die without anything being adversely affected. I run a HA-Proxy front end that balances the load between the two sql servers. I can add more MySQL servers as I may need to, very easily (even in geographically different places). Takes minutes, not hours to bring a new one online. Likewise, I have two web servers, both running identical production copies. Again, the load is balanced to direct queries to the least busy server. I can add more servers whenever I like, and either one can die without affecting anything else. As a matter of fact, I can have either web server die at the same time as either sql server, and the web site is still up - this is called “High Availability”. Because of storing the session data in database, if you are on web server A and it dies suddenly, your next page access will come from web server B and the user will never even know it. If the Web servers were storing the session data in a local file instead of the database, then the session would be lost when the web server died and the user would have to log in again and begin a new session on the other web server.

So yes, I like sessions being stored in database. In all of our testing, there is no noticeable slowdown, and it enables us to do many things that improve the responsiveness, robustness, and metrics of the overall system.

Sorry for the long winded explanation, but we have spent many hundreds of engineer hours analyzing performance & resilience metrics and refining our ideal scalable cluster. I guess I am like a proud papa describing my daughter’s school performance. :wink:

Dave

#7

Sorry for the long winded explanation, but we have spent many hundreds of engineer hours analyzing performance & resilience metrics and refining our ideal scalable cluster. I guess I am like a proud papa describing my daughter’s school performance.

Nothing wrong with that, tnx for the explanation. We have tests like these on our list for a long time, so it’s worth looking at the experiences of others.

#8

I see what you mean and understand your point uncle Dave :slight_smile:

It is really a debatable thing again, and another matter of positives and negatives huh I see :smiley:

We admire your nice way of explanation and how you putting it all straight forward for everybody to learn, as Albert said, it is always nice to have a look at other people experience.

Once more, thanks a lot for your time and the decent way of explaining the idea… you reminded me of the way that Albert explains something, so direct to the point and simplifying the tough stuff, just like earlier today I was watching old webinar for Albert about paypal (I wondered how I didn’t see it before!!) he kept saying it is simple, rr says LDAP is simple, all that code albert scrolling down 2km of code it is simple loooooooool guys you are so helpful in facing hard times making things feel easier and more fun :smiley:

#9

I am really looking forward to someday when NetMake sees fit to host a ScriptCase Developers Conference, we can all meet face to face.

Dave

#10

[QUOTE=daveprue;33399]I am really looking forward to someday when NetMake sees fit to host a ScriptCase Developers Conference, we can all meet face to face.

Dave[/QUOTE]
we are looking to organize one here in Spain. We have good food and good weather

#11

Sign me in.

#12

Well I like good food and good weather. Forget SC and let’s go to the beach.

#13

Albert, Jelly fish are there, forget the beach, lets focus on food and good weather.

Sign him in Giu, he will come. rr will come too.

#14

Beaches don’t excite me.

We have 7107 islands here, it’s hard to buy land that is not beachfront.

#15

Ok Dave is coming too, sign him in Giu. Food and weather Dave, food and weather.

#16

I will create a post about the event too, we are looking about details (placement, hotels and so on…)

#17

This is an old topic but the “Save Session Data in Database” feature described sounds exactly like what we need: we need to deploy a scriptcase application on an existing cluster of web servers. All the nodes in the cluster have access to an Oracle database and storing the session data in the database would be ideal for us. Is this feature still available? Could somebody please indicate where is this setting and how to enable it?

Thanks,
Eduardo

#18

It’s at the bottom of Options > Settings > System Settings

1 Like
#19

After enabling “Use session in database” and “Show an Option on the deployment wizard to store the PHP session variables in a Database”, selecting “Deploy Applications” presents an additional prompt labeled “Store the session in the database”. Checking the option results in being prompted for 3 values:
Connection (Deployment Environment)
Table name
Schema name

Any chance you could briefly describe what is supposed to be entered in each field?
Can any of these 3 values be left blank (so that, presumably, a default value is used)?
Will the table be created automatically if it doesn’t already exist?
I’ve been looking for a description of these fields and all I could find was an unanswered post from somebody who had this question as well.

Thanks.

#20

I am not using it myself

Check this link