Jump to content

#RequireAdmin - Only need it for certain functions


Recommended Posts

My program is designed to run under the context of a limited user. It requires an admin user login for some functionality, so once that is gathered, it runs a 2nd instance of itself with the admin user privileges. I would like to only have the #RequireAdmin activate under the 2nd instance. However, it seems no matter where in the code I put #RequireAdmin, it prompts each time the program is run at all. Is there a way to get past this?

Link to comment
Share on other sites

RunAs() perhaps.

Ok, let me clarify ...

1. Tool run under limited user context.

2. Admin user logs into the tool with their admin credentials. The tool authenticates the admin user's credentials against AD.

3. Tool runs 2nd instance of itself using RunAs, with the admin user's credentials.

4. 2nd instance of tool performs admin level task, then closes.

Where I have a problem is at #4. In Windows 7, it has been established that, even with user admin privileges, the tool cannot successfully write to certain parts of the registry ... See

I don't want the tool to display the UAC prompt unless one of the functions requires that level of access. However, it seems, no matter where in the code I put #RequireAdmin, say inside an "IF i need admin access THEN" statement in the 2nd instance, it always shows the prompt. Therefore, I get prompted both when the tool is run under the user context, then again when the tool runs itself again under the admin user context.

Link to comment
Share on other sites

#RequireAdmin is really a compiler directive, signified by the # prefix, meaning that it changes the header of the compiled executable (when used with the interpreter, these directives are processed before the main script). The location of the declaration in the script does not matter. If it is anywhere in the script, it will require administrative privileges.

As others have suggested, you may use a "runas" approach if it fits your needs. The other option would be to create two separate scripts (one with Admin privileges and one without) and have the less restrictive script call make calls the admin script.

Link to comment
Share on other sites

#RequireAdmin is really a compiler directive, signified by the # prefix, meaning that it changes the header of the compiled executable (when used with the interpreter, these directives are processed before the main script). The location of the declaration in the script does not matter. If it is anywhere in the script, it will require administrative privileges.

This is what I thought. Thanks for that clarification.

As others have suggested, you may use a "runas" approach if it fits your needs.

As it is, I use runas to call my script in elevated access, but UAC buggers it all up in Vista. I'm now looking into the link AdamUL sent.

The other option would be to create two separate scripts (one with Admin privileges and one without) and have the less restrictive script call make calls the admin script.

Not particularly an option. My script may be downloaded from a webpage. Therefore having multiple executables would be a problem. I need to keep it a single file. Edited by SlowCoder74
Link to comment
Share on other sites

You can use FileInstall to "package" the 2 programs into one. Compile the second script, then FileInstall it into the first script, you can use the Temp directory as the directory that FileInstall unpacks it to, then delete it when done.

If I posted any code, assume that code was written using the latest release version unless stated otherwise. Also, if it doesn't work on XP I can't help with that because I don't have access to XP, and I'm not going to.
Give a programmer the correct code and he can do his work for a day. Teach a programmer to debug and he can do his work for a lifetime - by Chirag Gude
How to ask questions the smart way!

I hereby grant any person the right to use any code I post, that I am the original author of, on the autoitscript.com forums, unless I've specifically stated otherwise in the code or the thread post. If you do use my code all I ask, as a courtesy, is to make note of where you got it from.

Back up and restore Windows user files _Array.au3 - Modified array functions that include support for 2D arrays.  -  ColorChooser - An add-on for SciTE that pops up a color dialog so you can select and paste a color code into a script.  -  Customizable Splashscreen GUI w/Progress Bar - Create a custom "splash screen" GUI with a progress bar and custom label.  -  _FileGetProperty - Retrieve the properties of a file  -  SciTE Toolbar - A toolbar demo for use with the SciTE editor  -  GUIRegisterMsg demo - Demo script to show how to use the Windows messages to interact with controls and your GUI.  -   Latin Square password generator

Link to comment
Share on other sites

You can use FileInstall to "package" the 2 programs into one. Compile the second script, then FileInstall it into the first script, you can use the Temp directory as the directory that FileInstall unpacks it to, then delete it when done.

Yeah, that sounds like it could work for what I needed, if it weren't for the requirement for literal source path. :( My program could be launched from any location.

I developed my own piggybacker utility, so now I can put my two progs together and it only prompts for UAC for the functions that require it. :)

Edited by SlowCoder74
Link to comment
Share on other sites

FileInstall only requires the literal source path at compile time, not the destination path. When the user runs it you can unpack it anywhere, and use a variable. Most likely @ScriptDir. You can even delete it when the main program exits if you choose, then unpack it again on the next run. Either way you can unpack only if FileExist returns false.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...