Results 1 to 12 of 12
  1. #1
    Join Date
    Oct 2005
    Posts
    87

    Unanswered: How to capture username from logon screen?

    I was thinking if it is possible to capture somehow username from logon box, when multiuser db is opened and then according to specified user, run specific objects and startup, e.g. macros. If user A entered, macroA runs, if user B, macro B, etc.


    Is it possible somehow?

    Thanks

  2. #2
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    should be
    currentuser() gives you the currently logged on Access user
    however, as its too easily faked I'd reccomend that you use the network logon ID, available through several fucntions (I use Dev Ashish's API calls, IzyRider uses something rom the scripting host).

    how you implement it depends on what you are tryimng to achieve. however prposing to use a macro tied to an individual user account is not smart - you are creating a massive maintenance task. every time a user leaves, changes role or starts you have to revisit every function call and rewrite macros. if you want ot go down this route consider instead assigning actions roles (groups) not users.

    A big but though, before embarking on this voyahe of discovery it may help if you cna identify what it is you are trying to do. Why should a macro run differently with user A comapred to user B - is there another way of achieving the same result. Just guessing, if you are using macros then the answer to that is undoubtably yes, use VBA instead.

  3. #3
    Join Date
    Oct 2005
    Posts
    87
    Quote Originally Posted by healdem
    should be
    currentuser() gives you the currently logged on Access user
    however, as its too easily faked I'd reccomend that you use the network logon ID, available through several fucntions (I use Dev Ashish's API calls, IzyRider uses something rom the scripting host).

    how you implement it depends on what you are tryimng to achieve. however prposing to use a macro tied to an individual user account is not smart - you are creating a massive maintenance task. every time a user leaves, changes role or starts you have to revisit every function call and rewrite macros. if you want ot go down this route consider instead assigning actions roles (groups) not users.

    A big but though, before embarking on this voyahe of discovery it may help if you cna identify what it is you are trying to do. Why should a macro run differently with user A comapred to user B - is there another way of achieving the same result. Just guessing, if you are using macros then the answer to that is undoubtably yes, use VBA instead.

    Ofcourse i understand that there might be more smart ways in creating everything differnet way, but i am learner atm and current task is pretty simpl ( i think).

    There are couple users (not much, max 5) total and each user (after his log in) should be able to open "invoice" form, which is standart to everyone.But he should be able to read only those records in that form, which are his only (they were entered with his name in "employee field" ).And the same thing for every user.

    So it is'nt hard for me to create 5 macros and set fillter option in them, and when user A logs in , macroA launches and he can see his records (in the form) only... Maybe there can be any better ways? e.g. how to limit records for user, to show only his records that he entered (his name is in one of the fields).

  4. #4
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    if all you are trying to do is limit visibility of rtecordds to the ones entered by a single user then odn't bother with macros

    alter your table to include a column called, say, userid (text 20 [or whatever the largest userid your network trolls permit]) should cover it

    place some code in your forms before insert event to copy the userid (which ever variant you prefer [although I'd suggest you avoid currentuser() like the plague]) to the relevant control - make that control non editable (so the user can't fake the userid

    set the recordsource for the form (probably in the forms on open event) to be select * from <mytable> where UserID="<specifieduser>"
    jobsagoodun

  5. #5
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926

    Getting users Login

    Attached is one way to get the user's login. Like Healdem mentioned, it may not be the best way.
    Attached Files Attached Files
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  6. #6
    Join Date
    Nov 2005
    Posts
    26
    Quote Originally Posted by healdem
    if all you are trying to do is limit visibility of rtecordds to the ones entered by a single user then odn't bother with macros

    alter your table to include a column called, say, userid (text 20 [or whatever the largest userid your network trolls permit]) should cover it

    place some code in your forms before insert event to copy the userid (which ever variant you prefer [although I'd suggest you avoid currentuser() like the plague]) to the relevant control - make that control non editable (so the user can't fake the userid

    set the recordsource for the form (probably in the forms on open event) to be select * from <mytable> where UserID="<specifieduser>"
    jobsagoodun

    Thanks, i'll give it a try.

  7. #7
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    Quote Originally Posted by pkstormy
    Attached is one way to get the user's login. Like Healdem mentioned, it may not be the best way.
    Paul thats a far neater way of getting the network logon than a API call

  8. #8
    Join Date
    Oct 2005
    Posts
    87
    Thanks, i used current user and it works for me....seems everything ok.

  9. #9
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    Quote Originally Posted by YZF
    Thanks, i used current user and it works for me....seems everything ok.
    Well if you want to use CurrentUser() then by all means do so, but, its a strong reccomendation that you use the network logon not the Access logon. Network Logon's are harder to fake, Access CurrentUser() is a piece of proverbial. Going down the CurrentUser() route exposes you to a serious problems, especailly if you want the userid to mean anything.

    But if thats what you want to do then go with it...

  10. #10
    Join Date
    Oct 2005
    Posts
    87
    Quote Originally Posted by healdem
    Well if you want to use CurrentUser() then by all means do so, but, its a strong reccomendation that you use the network logon not the Access logon. Network Logon's are harder to fake, Access CurrentUser() is a piece of proverbial. Going down the CurrentUser() route exposes you to a serious problems, especailly if you want the userid to mean anything.

    But if thats what you want to do then go with it...
    I don't need good security protection, because there are few users and they are all trusted...there could be no password at all...

    But what do you mean "if i want userid to mean anything" ? what problems might be then? Could you explain more in detail, thanks

  11. #11
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    What are you using the userid for? - answer so that a user can see the data they have entered.
    how do you know what data they have entered - either currentuser() or the network logon

    the network logon is difficult to fake - if you systems security & network procedures are tied down sensibly then there is probably one logon per account

    the current user is easy to fake - Access will happilly let you have mulitple concurrent instances of the same currentuser. If as you state you don't request a password then you are even more likely to get the userid ignored - don't beleive me, well go to a colleagues PC who has the application on already, open their copy of the application and his userid, not yours will pop-up. Maybe all your colleagues will 'do the right thing' and enter their userid - but somehow I doubt it.

    By going down the route you have chosen then you need maintian the workgroup file, add the userid's. if someone opens the application without the correct workgroup then your userid's are lost. Every time you update your copy of office, or your network trolls apply a security fix the workgroup file gets reset.

    By using a network logon you don't need to worry about security, if your network authenticates you as a user then thats fine in my book. Yes its nice to allocate security within Access - and the cheapest solution is to use Access, I tend to use the network logon as the access userid - users can sign on with whatever currentuser() they like (or not) I don't care who they say they are, I do care who they network says they are. most network logons require passwords to be changed periodically, most check the password is of reasonable size & type, soem advise on suitability. In workgroups you have no such control - even if you program it in, you can't stop a user tinkering (or not tinkering) with it.

    You have outlined a requirement that you want the userid so that users see their own data. Implementing a workgroup & pulling that data in based on currentuser() leaves you exposed to problems caused by either inadvertant or deliberate user activity - using the network logon takes that out of the equation - providing your users don't leave their PC connected to the network whilst they have an "out of office experience", or share their passwords (in most sites I work on these are immediate disciplinary offences [sometimes leading to a first & final warning]) then you can be confident that they and only they are the network logon.

    Finally your requirement is simple - just require a userid, using the network logon you don't even need to ask for a userid when access starts - the've already been authenticated by the network.

    Your network policies determine who has access to the data. The only area it falls down on is if you want to selectively control access to objects (queries, forms & reports) within Access - but I hybridise that by including the network logon in the workgroup file, assign permissions as if it were an Access logon and then query that workgroup to find the permissions.

    In summary you make life easier for the users - if life is easy then there is less chance that they will do stupid things (such as keeping a little black book of all their userid's & passwords beside the computer (or on a postit note on the screen). Its one less userid & password they have to remember.

    BTW how do you propose changes to data, can only the person who entered the data make changes to 'their' data?
    you need to ensure that direct table edits are banned - if they can do a direct table edit then the userid (irrespective of where you get it from could be compromised (the userid could change [to another userid, or to garbled userid]) - if the former then the record is still visible, if the latter then the record will disappear form the data entry screens but will appear in reports leading to discrepancies.

  12. #12
    Join Date
    Oct 2005
    Posts
    87
    I see.Thanks for reply, i actually have little bit different situation and i already tested currentuser() and it seems to work OK...will see what happens later

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •