Results 1 to 9 of 9
  1. #1
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926

    Unanswered: Finding the user's login ID

    I found an easy way to get the user's LoginID and thought I'd share it. Any feedback on this would be welcome. I've been successful in utilizing it.

    Use the code below to get the user's login id (this might be helpful):

    Function GetUser() As String
    '** Procedure to Get the User's Name from the Windows Login
    GetUser = Environ("Username")
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  2. #2
    Join Date
    Sep 2003
    Location
    MI
    Posts
    3,713
    Quote Originally Posted by pkstormy
    I found an easy way to get the user's LoginID and thought I'd share it. Any feedback on this would be welcome. I've been successful in utilizing it.

    Use the code below to get the user's login id (this might be helpful):

    Function GetUser() As String
    '** Procedure to Get the User's Name from the Windows Login
    GetUser = Environ("Username")
    I hate to say this but "Yeah, we know" ... I believe this (Environ) has had previous postings ...
    Back to Access ... ADO is not the way to go for speed ...

  3. #3
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    Yeah we know...
    Yeah Environ() has had previous postings
    Yeah its not a good idea to use it for security information, its probably OK for path info, but I wouldn't trust it for anything you *HAD* to rely on

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

    User name

    I didn't see it anywhere already so I started the thread. If it offended someone, I apologize - it wasn't meant to be a "yeah we know" type of response. I'm curious (with a little more detailed explanation) on WHY you wouldn't rely on it (that's the kind of feedback I was looking for). I have several other ways of getting the LoginID but what's the drawbacks on using this way besides just saying generically for security information?
    Last edited by pkstormy; 02-18-05 at 19:45.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  5. #5
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    Paul
    equally apologies if the "yeah we know" caused offence - it wasn't meant to, it came at the end of a b!!!d day at the end of a b!!!d week.

    If you search on this forum for environ you will see it has been covered before on this forum, hence why I didn't give it a fuller reply, thinking you may look back through the archive

    the key problem with environment variables is that they are easily spoofed or reset- just try typing, in a DOS command window
    set environ(USERNAME)=MyFakeUser
    where MyFakeUser could be anyone with authorities userid, you app will then think the perosn running the app is that person. There are other problems to do with how the environ variables are maintained and set. moral of the tale you can't trust them.

    A far safer technique is to use an API call for any security realted infroamtion. Environ is great for non security minded stuff like the users path, temp file location etc but I reppeat its no to be trusted for Security related information.

  6. #6
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    healdem: never thought about your DOS command before - interesting!

    any implications for ntlogin security in SQL-Server??

    i use a variation on Paul's theme to get the login:
    Dim wshNetwork As Object
    Dim strLogin as string
    Set wshNetwork = CreateObject("wscript.network")
    strLogin = wshNetwork.userName

    does this also get screwed by your DOS command?
    i don't have the courage to check for myself --- if my machine goes south i have a looooooong drive to physically connect to the LAN before rebuilding my machine.

    as for "yeah, we know":

    this site is packed full of repeated questions & answers - every conceivable trick with a combo has been discussed at least 50 times, yet we still see 10 combo questions a day!
    ...same for concatenation.
    ...same for date mainipulation.
    sooner or later someone has to get all the good stuff here organised into some sort of structure.

    meanwhile, it's better to post a "yeah, we know" item than to keep silent - you can be sure that it WILL be useful to someone: not everyone visiting here is in the "we know" set, and the seach feature here is just not good enough!

    izy
    currently using SS 2008R2

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

    Login ID

    Thanks guys, I appreciate the explanation and didn't mean to get snappy. Since I just started on this site a few months ago, I haven't seen all the posts in the past (I did try a search on trying to find the LoginID but probably didn't search on the right key words.)

    I'll stick with the:
    Dim wshNetwork As Object
    Dim strLogin as string
    Set wshNetwork = CreateObject("wscript.network")
    strLogin = wshNetwork.userName

    to get the LoginID (or use the API call I've written) - only problem was that the API call was causing a conflict on the login script with outlook and drive mapping loading simultaneously on only ONE of our machines (out of 75 other machines where it works flawlessly.) Since this particular machine was built by the networking guys (the others are all Dell machines or "toasters" connecting to terminal server via citrix), I think it's something with the way they built the machine/installed the software/drivers, etc., but trying to convince a network person that they might have built a machine wrong is like banging your head against a brick wall. The Environ was something someone else recommended to use instead of the API call so I thought I'd throw it out there and see what the pro's and con's were and thought it might be useful to others not knowing that it was already posted and critiqued. I have to say it does work though in that it doesn't cause a conflict on the login script but it's not my ideal solution.

    I've also noticed some things are getting repeated since I've been on this site. Guess there's no way around that. I try and do a search to see if something similar is out there before I make a post and try to throw things out there I think will be helpful if I don't see it already posted.

    I'm not sure if this site is supposed to be a response only site or a "here's a tip" type of site but I'm learning some of the site rules.

    Thanks again for the additional info and bearing with the repeated post.

    Not to get off the subject, but our network guys are very anti-Microsoft and extremely pro-linux and pro-open source. They've made my life a little difficult at times with trying to push non-microsoft products (I can't design ASP pages, use MAPI, etc. because they refuse to use IIS as well as other things from Microsoft for networking.)

    They've pushed me to get away from SQL Server and go to MySQL but I've used SQL Server since version 6.5 (now use 2000) and have a lot of faith in the product (and proved it's value to the company by never losing any data, ease of use, etc..)

    They have a linux-microsoft networking system setup (and really bitch about roaming profiles and how Microsoft screwed it up which they say is the reason my desktop icons get moved around all the time.) They often have difficulties getting linux and Microsoft to work together (and hate the Microsoft licensing issues which they'll use as an excuse any chance they get) and are always trying to find open-source work arounds. One example which I can partially agree with is that we've switched to Mozilla Firefox for a web browser because they say IE is so full of exploitable holes which would comprimise our system. Since the state of WI uses Microsoft products (i.e. Office) and we administer programs for them, it's kept my concept of continuing to use the Office products and Access alive (plus the fact that I've got about 50 key programs designed around Access and have a check-writing system which works flawlessly producing 2000+ rebate checks each month). I'm wondering if you guys have any feedback on this? I'm not anti-open source or anti-linux but I do think I get some bogus reasons at times from them on why linux is such a superior operating system and in their opinion - "Microsoft is a piece of #$#@." They'd also really like me to design my programs using something open-source based that works with linux verses Access. Thus the company life of a Database Administrator verses a Networking Administrator with different ideologies. Any opinion on this? I'd really appreciate any pros/cons you have on linux verses Microsoft.
    Last edited by pkstormy; 02-19-05 at 14:59.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  8. #8
    Join Date
    Nov 2004
    Posts
    32
    I'm not sure whether or not this is a response only site, but I do see other tips now and then, so I think not.

    One small point I would like to make. Some hints and tips do seem to get buried with age, and it's not always easy to find them especially as knowing the right key word to search against usually means you know all you need to know anyway. Also in different versions of Access things have moved on. It mught be useful to know that something that took many lines of code in say '97 can be achieved with one command in XP.

    As for the open source issue. I love the concept of Linux but struggle to get it to work as easily as MS. That said it seems to be inherently more secure - a big factor.

    To be honest, thugh, I've yet to see another small to medium sized RDBMS that can touch Access either on Windows or Linux. It's the strongest reasn to stick with Microsoft IMHO. That said the big argument for mySQL and .php has to be cost, expecially for a small business.

  9. #9
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    Well said DerickM. I am not aware of any similar product to Access in the windows or **IX world. Various people have tried to suggest Filemaker.

    BTW: I thought Chillisoft used to make an ASP subsytem for Apache on Linux and Windows

    Pesonally I couldn't give a stuff what the OS is, what the application is, what the network infrastructure is - providing it works, does what it is supposed to do and has a welcomong devlopment environment. I've yet to see anything that comes close to the Access IDE in the open source world.

    Its bad enough keeping up with the various flavours of SQL, forms & other guff without some zealot demanding you use box "A" becasue 'they' like it. Often such prefernece are personal or highly selective or distorted. The true cost is not the purchase or licensing costs its the whole shebang from inception, design, implementation and support over the life time of the product.

    Until someone comes up with a reasoned alternative I'll stick with Access as my weapon of choice for db applciations. Despite others claims that Access isn't an enterprise capable application it does the job for me. And in the few areas where it is unable to perform then I'll resort to VB or VB NET, or PHP.

    I suppose the alternative is to go to your Network Trolls and get them to evaluate the RAD alternatives for Access and see what they come up with. Using MySQL in place of SQL server - fine, but MySQL is as well featured as SQL server, may be it will get there. But in the mean time they see the cost benefit of not having to buy SQL server licences, but they don't see the costs of retraining and switching the development function, and posssibly of much more significance the costs of gettign someone in at short notice to fix faults.

    There's a heck of a lot more SQL server experts around than MySQL.
    There are a lot fewer tools in SQL Server, but they are often much better developed and true production tools than work in progress, which so many of the open sourdce tools seem to be

Posting Permissions

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