Getusername function

[theDBguy]

I think you missed my point. Also, they can use whatever password they like. Assuming the login eliminates 50% of the user verification AND allows a random person to sit down at your desk as you.

I guess I did miss the point. I thought you were saying a login form is necessary.

 

[Pat Hartman]

When a log in is deemed necessary by the customer, you need to test the security such as it is. You seem to have decided to bypass the security check entirely. When you assume that only the user who ever opens the app is the one authorized, then you are just giving up. Why bother at all, let alone use 2 pieces of data instead of 1 to identify a user? Then assuming you actually want to test security, do you go to the user's desk to test as him or do you change your computer settings so you can pretend to be him?

Most apps don't need real security since they operate in a secure environment and people tend to not desk hop so I have no problem using the computer's credentials rather than a log in form when you don't need any security at all.

 

[theDBguy]

When a log in is deemed necessary by the customer, you need to test the security such as it is. You seem to have decided to bypass the security check entirely. When you assume that only the user who ever opens the app is the one authorized, then you are just giving up. Why bother at all, let alone use 2 pieces of data instead of 1 to identify a user? Then assuming you actually want to test security, do you go to the user's desk to test as him or do you change your computer settings so you can pretend to be him?

Most apps don't need real security since they operate in a secure environment and people tend to not desk hop so I have no problem using the computer's credentials rather than a log in form when you don't need any security at all.

Hi Pat. All I need to grab from the session is the user's network username. With that, I can tell what they have permission to do within the app (role-based). Each user, of course, has their own unique network username, so nobody can impersonate another. In other words, the app is secured with just the username available, just as it was when it had a login form with a username and password - nothing is really bypassed, except the part where the user is asked to enter their password and then have to be verified. I got rid of that. No unauthorized person can use the app because of their assigned network username. Hope that makes sense...

 

[Pat Hartman]

I hear you and I disagree.

 

[theDBguy]

I hear you and I disagree.

I understand. I hope you're not saying your way is the only way to do security. I don't think my app is less secure than it was when it had a login form.

 

[Pat Hartman]

It is less secure since it does not require a password. No Access app is truly secure so it is nothing to argue about. And you didn't mention how you tested as "Tom" to ensure the "security" actually works correctly.

 

[theDBguy]

It is less secure since it does not require a password. No Access app is truly secure so it is nothing to argue about. And you didn't mention how you tested as "Tom" to ensure the "security" actually works correctly.

Hi Pat. You know how Active Directory works, right? Only one Tom can exist in the network. So, when GetUsername tells me it's Tom, there's no doubt in my mind it's him. I don't need to check his password, the OS does that job for me.

Actually, in our system, we don't use passwords, because we log in using a CAC, which cannot be spoofed.

Hope that helps clarify things on my end. Thanks.

 

[theDBguy]

And you didn't mention how you tested as "Tom" to ensure the "security" actually works correctly.

Oh, and as for testing, I simply test it on myself. If the logic works for me, it should also work for Tom, right? To verify that, then I ask Tom to test the app after I'm done. But like I said, if Tom and I have the same role, then I don't really need to do extra testing specific to Tom or anybody else who has the same permissions as me. Does that make sense?

 

[Pat Hartman]

So you change your own security each time you want to test a different profile? Then do you change it back? Access is hardly secure so there is no point in my harping on this. I would not use that method if I needed to implement some semblance of security. I would want to establish several levels of security for different groups and then be able to log in as a member of each group, one at a time to ensure that each group is correct. Changing security settings on the fly doesn't seem very "secure" to me. Having to change your own security every time you want to test a security change just leaves too much room for error for my taste. Many of my apps have no security at all. In that case, I just capture their UserID the way you are doing it and use it for controlling paths, and logging who made a change, etc.

 

[theDBguy]

So you change your own security each time you want to test a different profile? Then do you change it back? Access is hardly secure so there is no point in my harping on this. I would not use that method if I needed to implement some semblance of security. I would want to establish several levels of security for different groups and then be able to log in as a member of each group, one at a time to ensure that each group is correct. Changing security settings on the fly doesn't seem very "secure" to me. Having to change your own security every time you want to test a security change just leaves too much room for error for my taste. Many of my apps have no security at all. In that case, I just capture their UserID the way you are doing it and use it for controlling paths, and logging who made a change, etc.

Now, it looks like you're the one who missed my point. In fact, I am doing exactly as you described. I am not changing the security settings on the fly. Instead, I move myself to different security levels when testing. So, I think we're both saying the same thing, except we're not connecting since our environment experiences are not exactly the same.

 

[Pat Hartman]

move myself to different security levels when testing.

That is what I said. You are changing security settings for yourself. I wouldn't test security that way.

 

[theDBguy]

That is what I said. You are changing security settings for yourself. I wouldn't test security that way.

Oh, I see. So, how would you test security exactly? Mind you, changing my role is for security testing is not overly complicated. It would be the same as someone getting promoted to a manager status or one who was being discharged.

 

[Pat Hartman]

So, how would you test security exactly?

I sign in with an ID that has the security level I want to test. I don't need to change anything. That way I don't accidentally mess up the security settings that I am trying to test. If you have to change the settings to test them, can you ever be sure that you didn't make a mistake?

 

[theDBguy]

I sign in with an ID that has the security level I want to test. I don't need to change anything. That way I don't accidentally mess up the security settings that I am trying to test. If you have to change the settings to test them, can you ever be sure that you didn't make a mistake?

Ah, in our case, no one can impersonate anybody else, since we're using hard tokens. I'm not sure which mistakes you're concerned about. As I said, if the code logic works for one manager, it should work for all managers, it doesn't matter who they are. If I log in and couldn't perform the task I know I'm supposed to be able to, or vice versa, then I simply check if I'm in the right permission group (managers, users, etc.)

 

[theDBguy]

When a log in is deemed necessary by the customer, you need to test the security such as it is. You seem to have decided to bypass the security check entirely. When you assume that only the user who ever opens the app is the one authorized, then you are just giving up. Why bother at all, let alone use 2 pieces of data instead of 1 to identify a user? Then assuming you actually want to test security, do you go to the user's desk to test as him or do you change your computer settings so you can pretend to be him?

Most apps don't need real security since they operate in a secure environment and people tend to not desk hop so I have no problem using the computer's credentials rather than a log in form when you don't need any security at all.

I've reread this post, and I think this is where the disconnect happened. You assumed I grab the username and don't do anything with it with regards to doing a security check. In fact, I compare the username to a list of group permission to assign the appropriate restrictions for that user. Does that help clarify what I am doing?

 

[Pat Hartman]

Sorry. Someone else will have to explain this to you since I am not able to. As I said, Access is not secure anyway so it is silly to waste this much time on it. You are happy with your method and see no flaw in it. Fine.

 

[theDBguy]

Sorry. Someone else will have to explain this to you since I am not able to. As I said, Access is not secure anyway so it is silly to waste this much time on it. You are happy with your method and see no flaw in it. Fine.

Okay, regardless of what I am actually doing, are you saying there is absolutely no way to implement proper security without using a login form and password (Access or not)?

 

[Pat Hartman]

You assumed I grab the username and don't do anything with it with regards to doing a security check.

Not at all. I'll try one more time. I am not saying that the security check isn't being done. I am questioning your method of TESTING. Having to change the security settings on your account on your computer each and every time you want to test is not a safe method of testing the settings, especially if they are complex. That is why if I actually wanted to implement security, I would use a log in form. It is for MY convenience when testing, not because it is "better".

 

[theDBguy]

Not at all. I'll try one more time. I am not saying that the security check isn't being done. I am questioning your method of TESTING. Having to change the security settings on your account on your computer each and every time you want to test is not a safe method of testing the settings, especially if they are complex. That is why if I actually wanted to implement security, I would use a log in form. It is for MY convenience when testing, not because it is "better".

I see. But in my view, testing is only a small (yet very important) part of development. So, making those minor adjustments don't seem cumbersome to me. Would you feel better if I don't modify my own permission and simply ask another user to test the app for me? That approach is akin to you logging in with their ID; except as I said earlier, that's not something we can do with CACs.

Having a login form may be convenient to the developer, but it can be cumbersome to the users. There is only one developer, but there are many users. So, I would rather inconvenience myself than annoy my users. Like I said earlier, once I told them they no longer need to remember a password, they were all very happy.

 

[Pat Hartman]

But in my view, testing is only a small (yet very important) part of development.

You do it your way. I'll do it mine.