Getusername function

[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?

 

[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.

 

[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.

 

[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?

 

[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)?

 

[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.

 

[theDBguy]

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

The funny thing is, sometimes, I do it your way too.

 

[theDBguy]

And I also do it your way but if I actually want to implement security, I do it my way. My choice isn't random.

My choice also depends on the client requirements and environments, but rarely for my convenience.

 

[theDBguy]

Testing is important enough that you do it properly. Changing security settings on the fly can never be a valid method. Think about it. You build the security in your test environment to begin with. Then to test it you have to change it? Not a good plan. What if you forget and don't fix it before moving to production.

I can use more than one test plan, right? Like, one for each group or scenario? It's not that hard to add a step in the test plan to modify my membership, is it? Also, do you really consider moving a user from one security group as actually changing a security settings? If I add a new user to the system, am I changing security settings then?

 

[Gasman]

Time out guys, please?

This dialogue has been going on since post #18, and the dialogue has just been between the two of you. We are now at #45.

Can we please just agree to disagree?

 

[theDBguy]

Time out guys, please?

This dialogue has been going on since post #18, and the dialogue has just been between the two of you. We are now at #45.

Can we please just agree to disagree?

No problem. Apologies to the OP.