StrataFrame Forum

I would like to add the logged in user's user_id to the application object when they log in

http://forum.strataframe.net/Topic20413.aspx

By Marcia G Akins - 10/29/2008

So can you help me with this Smile ?

Thanks

By Edhy Rijo - 10/29/2008

I don't quite understand your question, but in case this may help you, I have a method that will show up the current logged user in a ThemedLinkMenuItem:

AddHandler MicroFour.StrataFrame.Security.SecurityBasics.CurrentUserChanged, AddressOf UpdateCurrentUserInfo

 

''' <summary>

''' Update the Current User info on the main form.

''' </summary>

''' <remarks></remarks>

Private Sub UpdateCurrentUserInfo()

     '-- Show the current logged user info.

     Dim currentUserName As String = MicroFour.StrataFrame.Security.BusinessObjects.SFSUsersBO.RetrieveFullName(SecurityBasics.CurrentUser.UserPK, False)

     If SecurityBasics.CurrentUser.UserName.Equals("Administrator", StringComparison.CurrentCultureIgnoreCase) Then 

          currentUserName = SecurityBasics.CurrentUser.UserName

     End If

     Me.tlmUserInfo.ItemCollection("CurrentUser").Title = currentUserName

     Me.tlmUserInfo.ItemCollection("LoggedOnValue").Title = SecurityBasics.CurrentUser.LoggedOnAt.ToString

End Sub

By Marcia G Akins - 10/29/2008

Edhy Rijo (10/29/2008)
I don't quite understand your question, but in case this may help you, I have a method that will show up the current logged user in a ThemedLinkMenuItem:

AddHandler MicroFour.StrataFrame.Security.SecurityBasics.CurrentUserChanged, AddressOf UpdateCurrentUserInfo

 

''' <summary>

''' Update the Current User info on the main form.

''' </summary>

''' <remarks></remarks>

Private Sub UpdateCurrentUserInfo()

     '-- Show the current logged user info.

     Dim currentUserName As String = MicroFour.StrataFrame.Security.BusinessObjects.SFSUsersBO.RetrieveFullName(SecurityBasics.CurrentUser.UserPK, False)

     If SecurityBasics.CurrentUser.UserName.Equals("Administrator", StringComparison.CurrentCultureIgnoreCase) Then 

          currentUserName = SecurityBasics.CurrentUser.UserName

     End If

     Me.tlmUserInfo.ItemCollection("CurrentUser").Title = currentUserName

     Me.tlmUserInfo.ItemCollection("LoggedOnValue").Title = SecurityBasics.CurrentUser.LoggedOnAt.ToString

End Sub

I take it that this code requires that I have the Role Based Security module installed. Since I do not, this could be a problem Tongue

By Edhy Rijo - 10/29/2008

Marcia G Akins (10/29/2008)
I take it that this code requires that I have the Role Based Security module installed. Since I do not, this could be a problem Tongue

If you are not use RBS, then are you talking about Windows Logged User? if that is the case, I have not done that yet, but there are plenty of info in google on how to read the Windows current user.

By Marcia G Akins - 10/29/2008

Edhy Rijo (10/29/2008)
Marcia G Akins (10/29/2008)
I take it that this code requires that I have the Role Based Security module installed. Since I do not, this could be a problem Tongue

If you are not use RBS, then are you talking about Windows Logged User? if that is the case, I have not done that yet, but there are plenty of info in google on how to read the Windows current user.

No, I am not talking about Windows Logged User. My application has its own log in form and it has a table of application users in SQL server.

By Greg McGuffey - 10/29/2008

Marcia,



Well, you could just take a play out of the SF playbook and in your login code, raise a CurrentUserChanged event. Then handle this event to update whatever you need to.



As to were to save this off, you'd probably want to save it way down in a base/library class, that every other class is already referencing anyway (this should probably be were the other security code is also). SF uses static class/method to do this, so it is easy to access from anywhere: SecurityBasics.CurrentUser. This works very well, so if I had to roll my own security, I'd likely follow this sort of design. Does that make sense/help?


By Marcia G Akins - 10/30/2008

Greg McGuffey (10/29/2008)
Marcia,

Well, you could just take a play out of the SF playbook and in your login code, raise a CurrentUserChanged event. Then handle this event to update whatever you need to.

As to were to save this off, you'd probably want to save it way down in a base/library class, that every other class is already referencing anyway (this should probably be were the other security code is also). SF uses static class/method to do this, so it is easy to access from anywhere: SecurityBasics.CurrentUser. This works very well, so if I had to roll my own security, I'd likely follow this sort of design. Does that make sense/help?

Sort of. Thanks for your input.

By Trent L. Taylor - 10/30/2008

Basically he is telling you that since you have your own security to write your own logic that the RBS already has built in.  The SecurityBasics is totally useless of you are using RBS.  But what Greg was referring to is that we have a CurrentUserChanged shared event that can be handled and is raised when the logged in user is changed.  When this happens, the CurrentUser information along with all of their permissions, etc. are updated.  This ensures that you can always and reliably use the CurrentUser PK, user name, permissions, etc. and it is all event driven.  We have tapped into this event for a number of different purposes in our medical application which makes updating the environemtn based on the current users permissions much easier.  Also, we have a user stamp column on every table in our system so we can see which user created every record in our entire application.  There are a lot of benefits, but Greg was just trying to explain how the SF RBS works so you could write your own since you are already going down this road.
By Marcia G Akins - 10/30/2008

Trent L. Taylor (10/30/2008)
Basically he is telling you that since you have your own security to write your own logic that the RBS already has built in.  The SecurityBasics is totally useless of you are using RBS.  But what Greg was referring to is that we have a CurrentUserChanged shared event that can be handled and is raised when the logged in user is changed.  When this happens, the CurrentUser information along with all of their permissions, etc. are updated.  This ensures that you can always and reliably use the CurrentUser PK, user name, permissions, etc. and it is all event driven.  We have tapped into this event for a number of different purposes in our medical application which makes updating the environemtn based on the current users permissions much easier.  Also, we have a user stamp column on every table in our system so we can see which user created every record in our entire application.  There are a lot of benefits, but Greg was just trying to explain how the SF RBS works so you could write your own since you are already going down this road.

No - eventually I am going to purchase your role based security module because it is going to be cheaper for my client than having me write one from scratch Smile

By Marcia G Akins - 10/30/2008

Trent L. Taylor (10/30/2008)
Basically he is telling you that since you have your own security to write your own logic that the RBS already has built in.  The SecurityBasics is totally useless of you are using RBS. 

OK - I hate to be stupid but I just purchased the RBS module. Now how do I activtivate the license?

By Trent L. Taylor - 10/30/2008

Just open up the Activation client and deactivate your current license.  Then go back in and re-activate your license and you will be able to pick both the framework and RBS licenses.
By Marcia G Akins - 10/30/2008

Trent L. Taylor (10/30/2008)
Just open up the Activation client and deactivate your current license.  Then go back in and re-activate your license and you will be able to pick both the framework and RBS licenses.

Yeah - I figured that out right after I posted that reply Blush

By Marcia G Akins - 10/30/2008

Ok, Trent. Now you really asked for it Tongue

I already have a table in my existing application to store user names and another for their roles. Can I continue to use my tables and still hook into RBS just for the purposes of saving the current users login id?

By Trent L. Taylor - 10/30/2008

Ehhh....that could be tough.  Not saying it is impossible, but you will have to "sync" up the SFSUsers and your users tables so that RBS authenticates off of the SFSUsers versus your users.  What I would do is just write a conversion program that is run the first time the app is executed with the RBS that converts your existing users and roles into the RBS users tables and sets their permissions.  That is going to be easier than tryin to make two different applications work together.
By Marcia G Akins - 10/30/2008

Trent L. Taylor (10/30/2008)
Ehhh....that could be tough.  Not saying it is impossible, but you will have to "sync" up the SFSUsers and your users tables so that RBS authenticates off of the SFSUsers versus your users.  What I would do is just write a conversion program that is run the first time the app is executed with the RBS that converts your existing users and roles into the RBS users tables and sets their permissions.  That is going to be easier than tryin to make two different applications work together.

Hmmm. That is an idea. I could actually synch up the existing data myself before I give the client the next build. Then I suppose I could add some code to my Users form to update the RBS data with the user data that has been added or edited. It is unlikely that they will add new roles, but just in case they do, I could add code to update the roles in RBS. Do you think that would work? The only snag I can see is that the PK's have to match.

By Trent L. Taylor - 10/30/2008

That should work...the only thing that I don't understand is why PKs would have to match...unless you are storing these off presently in other tables for auditing purposes...then I could see that.  But as for authentication, it won't matter.
By Marcia G Akins - 10/30/2008

Trent L. Taylor (10/30/2008)
That should work...the only thing that I don't understand is why PKs would have to match...unless you are storing these off presently in other tables for auditing purposes...then I could see that.  But as for authentication, it won't matter.

OK - I see what you are getting at. Later, when I implement audit loggin, I can let then view the log by user as the user is stored in RBS.

I have been heads down in the RBS documentation to see how I add security to my app but I must have taken my stupid pills today Tongue I cannot see how to get started. It looks like I have to add a new security project to my solution. Is that correct?

By Trent L. Taylor - 10/30/2008

No, you can retro-fit the security into your application.  But the easiest way to figure out what to add is to create a new security project, then open up the Appmain.vb or program.cs depending which language you are using, and rob the code out of there that is security specific and then add it into your application.
By Marcia G Akins - 10/30/2008

Trent L. Taylor (10/30/2008)
No, you can retro-fit the security into your application.  But the easiest way to figure out what to add is to create a new security project, then open up the Appmain.vb or program.cs depending which language you are using, and rob the code out of there that is security specific and then add it into your application.

Thanks. I will try that. Just in case there is a problem, I have already backed up my existing application BigGrin

By Marcia G Akins - 10/30/2008

Trent L. Taylor (10/30/2008)
No, you can retro-fit the security into your application.  But the easiest way to figure out what to add is to create a new security project, then open up the Appmain.vb or program.cs depending which language you are using, and rob the code out of there that is security specific and then add it into your application.

I can tell that this is going to be another one of those days Sad

I created the new security project and then tried to enter roles using the security editor. Even though I ran the script to add the SFS* tables to my application database, when I added the roles, the application added them to the tables in the StrataFrame database. What do I need to do to get the security editor to add the users. roles, etc to the tables in my database?

By Greg McGuffey - 10/30/2008

When you use the Security editor via the SF menu, you will pick/create a project. The data is then stored in the SF database, using the project to keep things separate. When you update roles/permissions this way, you will then need to deploy the security data to your database.



The easiest way to do this is to use the DDT to manage it. However, I believe that if use it and have your security tables in your app database, you have to also use the DDT to manage deployment of your entire database (I think the newest versions allow for custom/non-DDT sprocs and views, but I think all tables still need to be deployed via the DDT). If is the case for you, then open the DDT and just redeploy the database. Typically, when you add the security tables to the DDT, it adds the appropriate data packages also, so it is a snap.



If you aren't using the DDT, it gets more interesting. If you use the security editor via VS or the SF menu to update roles, then you need to move the data out of the SF database yourself. I haven't done this...it just looked like too much fun and I have a weak liver Ermm For more help on deploying security data, see the "Deploying Security Data" topic in the RBS section of the help file.



What I've done is a hybrid. I just have two databases: one for the app and one for security. That way I can use scripts to manage my app database and DDT to manage the security database. When I started, there were reasons I chose not to use the DDT for my application database, but if I were to start out now, those reasons have diminished a lot, so I might just use the DDT for both now.



However, you can make a call to the security dialog within an app and then it uses the security key to identify the appropriate data source that contains the SFS* tables for your app. You'd use a call like this within a project setup for security:



using (SecurityDialog loDialog = new SecurityDialog())

{

  loDialog.ShowDialog();

}




See the "Calling the Security Maintenance Dialog" help topic in the RBS section of the help file for more info.



Even if you do this, you will still need to deploy the data from your dev environment to your test and then production environments. However, you could use this to skip the whole deployment thingy while figuring out the RBS at this stage.



Good luck!
By Marcia G Akins - 10/30/2008

Greg McGuffey (10/30/2008)
When you use the Security editor via the SF menu, you will pick/create a project. The data is then stored in the SF database, using the project to keep things separate. When you update roles/permissions this way, you will then need to deploy the security data to your database.

The easiest way to do this is to use the DDT to manage it. However, I believe that if use it and have your security tables in your app database, you have to also use the DDT to manage deployment of your entire database (I think the newest versions allow for custom/non-DDT sprocs and views, but I think all tables still need to be deployed via the DDT). If is the case for you, then open the DDT and just redeploy the database. Typically, when you add the security tables to the DDT, it adds the appropriate data packages also, so it is a snap.

If you aren't using the DDT, it gets more interesting. If you use the security editor via VS or the SF menu to update roles, then you need to move the data out of the SF database yourself. I haven't done this...it just looked like too much fun and I have a weak liver Ermm For more help on deploying security data, see the "Deploying Security Data" topic in the RBS section of the help file.

What I've done is a hybrid. I just have two databases: one for the app and one for security. That way I can use scripts to manage my app database and DDT to manage the security database. When I started, there were reasons I chose not to use the DDT for my application database, but if I were to start out now, those reasons have diminished a lot, so I might just use the DDT for both now.

No, I am not using DDT. I just want to know how to point the security maintenance application to the SFS* tables that I have created in my application database. Obviously, my client does not have the Stataframe database on his site and it would be inconvenient to have his application blowing up when he tries to maintain users. I have search the documentation and I can't find anywahere that it tells me how to do this.

By Ivan George Borges - 10/30/2008

Hi Marcia.

Have a look at Role-Based Security / Defining Security within the Application / Deploying Security Data.

Then you will find a topic about Deploying Security Data Without the DDT.

But if I were you, I would consider getting the DDT too. Wink

By Marcia G Akins - 10/30/2008

Ivan George Borges (10/30/2008)
Hi Marcia.

Have a look at Role-Based Security / Defining Security within the Application / Deploying Security Data.

Then you will find a topic about Deploying Security Data Without the DDT.

But if I were you, I would consider getting the DDT too. Wink

I have my husband the DBA to handle the stored procedures Smile

I am pretty comfortable in SQL Server, so I really do not need it. I found the topic and I did run the script. My problem is that when I run the security maintenace form and run it, it populates the tables in the Strataframe database and not my application database. All I want to know is how to make it update the tables in my database and I can't seem to find an answer to that question anywhere.

By Ivan George Borges - 10/30/2008

Whenever you run it from the VS IDE, you will get the data from the StrataFrame database.

You will have to script the import procedure to get that info from the SFS tables in the StrataFrame database and then append them to your client's database or to your testing database in you network. So, when you run the application and point it to its database, you will be speaking to the SFS tables in it.

By Marcia G Akins - 10/30/2008

Ivan George Borges (10/30/2008)
Whenever you run it from the VS IDE, you will get the data from the StrataFrame database.

You will have to script the import procedure to get that info from the SFS tables in the StrataFrame database and then append them to your client's database or to your testing database in you network. So, when you run the application and point it to its database, you will be speaking to the SFS tables in it.

OK - I finally did figure that one out. So I created a simple security based application with one form that called the maintenace form and got an error when I tried to save a new user saying that a solumn in my users table did not exist. So apparently the script provided to generate the tables in my database is not correct Sad

Thanks for the assistance.

By Greg McGuffey - 10/30/2008

So apparently the script provided to generate the tables in my database is not correct.




I haven't upgraded to the latest version (1.6.6), but the link in my help file is to a script from 2006. There are no auditing tables in it, so looks like SF probably needs to provide a new script for the security tables.
By Marcia G Akins - 10/30/2008

Greg McGuffey (10/30/2008)
So apparently the script provided to generate the tables in my database is not correct.


I haven't upgraded to the latest version (1.6.6), but the link in my help file is to a script from 2006. There are no auditing tables in it, so looks like SF probably needs to provide a new script for the security tables.

Well, I have given up on trying to integrate RBS into my app for now. I have too much stuff to work on so I can take this app live within the next week or so. I can deal with the discrepancies. I have my own set of utility programs that can create a working script (correctly - not like how SQL Server does it BigGrin ) from a set of tables.

When I have phase 1 finished, I will revisit the RBS integration.

Thanks for all the help Smile

By Larry Caylor - 10/30/2008

1. Make sure you can connect to the internet.

2. From the StrataFrame menu in VS select License Information to bring up the Activation Client.

3. Click the Next button and answer Yes to the "Are you sure you want to deactivate ALL of your MicroFour products.

4. Rerun the License Activation Client.

5. Enter you Microfour user account (not your forum account) ID (e-mail) and password.

6. Select the network adaptor you wish to bind to and press Next.

7. Select the items you wish to activate (RBS should be listed) and press Next.

8. You should see a "Successfully Activated!!" message.

-Larry

By Larry Caylor - 10/30/2008

Sorry. Didn't see you got beyond the activation part.
By Trent L. Taylor - 10/30/2008

When you get back to it you make make it more simple.  The SFS tables and the SFS views that are in your StrataFrame database are required for your application (minus the SFSprojects table).  But other than that they will be identical.  So if you are not using the DDT, you can have SSMS create the scripts for you and then deploy them that way.  I will be sure to update the help docs with the manual scripts.  Most people use the DDT....including us.  We too have a very deep understanding of SQL Server, this is not the point of the DDT.  The DDT is designed for deployment and making deployment much easier.  This is why the DDT has a wizard that allows you to just click which RBS project you are using, and it will bring in all of the data for your security project.  If you do this manually, well, it is going to be much hard to distribute your permissions, etc.  It doesn't mean that it is not possible, it just requires more elbow grease.

But I know what you mean about staying on schedule.  When you start back up, start with the RBS sample, it might speed things up since you are a strong developer and a sample may be all that you need.

By Marcia G Akins - 10/31/2008

Trent L. Taylor (10/30/2008)
When you get back to it you make make it more simple.  The SFS tables and the SFS views that are in your StrataFrame database are required for your application (minus the SFSprojects table).  But other than that they will be identical.  So if you are not using the DDT, you can have SSMS create the scripts for you and then deploy them that way.  I will be sure to update the help docs with the manual scripts.  Most people use the DDT....including us.  We too have a very deep understanding of SQL Server, this is not the point of the DDT.  The DDT is designed for deployment and making deployment much easier.  This is why the DDT has a wizard that allows you to just click which RBS project you are using, and it will bring in all of the data for your security project.  If you do this manually, well, it is going to be much hard to distribute your permissions, etc.  It doesn't mean that it is not possible, it just requires more elbow grease.

But I know what you mean about staying on schedule.  When you start back up, start with the RBS sample, it might speed things up since you are a strong developer and a sample may be all that you need.

Hi Trent.

I really appreciate all the help you and all the others here have given me to help me get up to speed on the framework. What I am thinking is that when I get back to retrofitting this application after go live, I may just move all the RBS tables into the application and set everything up using the app. Would that work?

By Trent L. Taylor - 10/31/2008

If you only plan to have one RBS application, then that would work.  But as soon as you were to create your second application, then you would have a problem. 
By Marcia G Akins - 10/31/2008

Trent L. Taylor (10/31/2008)
If you only plan to have one RBS application, then that would work.  But as soon as you were to create your second application, then you would have a problem. 

OK. Then I will handle thos in the VS IDE and export the data to the tables in the app Smile

Thanks again

By Trent L. Taylor - 11/1/2008

That would be the safest way to go. Smile