02:06:43 AM
3KC1FFIAF
Did you check the HTML when this was happening? Could this be some issue where the value is being clipped due to sizing or something? I can't imagine that this value would show up with a misisng letter - it comes straight from the OS's GetUser() API call. IAC, if the user is authenticated - that's all that matters.
+++ Rick ---
Abcolutely confirmed that no such user exists, and during the time WC reported the use name with the missing letter, the server reported the user authenticated with the correct name. This name discrepancy only pops up now and then, but I was hoping it might indicate what my problem really is. Even without that problem showing up, the browser works and the httpget does not work ever, I think because there does not exist an anonymous user.
Could that be? Why would it care if an anonymous user exists or not?
Yeah that's significant. But the only way you can see a user name there if there's somebody logged in with that name...
+++ Rick ---
And . . .
On the status page, under "authenticated user", sometimes wc shows "administrato" instead of administrator". Note the missing last letter. is this significant?
And . .
The wwhttp.httpget call to UpdateExe sometimes succeeds if there is an anonymous user with access (although we use the authenticated user and never touch anonmyous), but always fails with no anonymous user at all.
I am using the dll you sent.
Tuvia,
The difficulty with configuration for Web Applications - and especially FoxPro Web Applications - comes from the fact that you have several different sets of permissions.
They break down like this:
- IIS Permissions - typically the Application Pool Identity
- DCOM Permissions - If running in COM mode this determines the FoxPro permissions
- OS Permissions - Used for IIS ACL access in Virtual Folders
IIS Permissions
The most important of those tends to be the Application POol identity which affects all of the Web permissions that your application requires *before* it hits your FoxPro server. IOW, all file access that IIS needs, that wc.dll/WebConnectionModule.dll needs. This also affects the temp file path.
These permissions are set in the IIS Application Pool's Identity setting. Typically for WWWC app this should be SYSTEM, or a high rights Administrator account. Needs file read/write access to temp folder.
To check and see what account you're actually running under bring up the IIS Admin Page | ISAPI/Module Admin Page and look for the Server Account. That's the account the Application Pool runs under.
DCOM Permissions or FoxPro Execution Permissions
If you're running in COM mode your fox server's permissions are determined by DCOM Impersonation or if not set through passthrough permissions from the IIS Permissions. If you're running in File mode then the logged on account or whatever account launched the application determines the security of the FoxPro app. This account needs full access to all the data, possibly the registry, remote data sources or any other resources that your application code needs.
To find out what account your app runs under use Sys(0) and echo that back in a Process Method. If you've copied the wwMaint features Use the Quick View of Settings and look up Application User Account.
OS Permissions
There are several sets of OS permissions required to make your Web app work right. First and foremost the Anonymous user needs to be included in the file permissions for the Virtual/Root Web folder or else you get log in dialogs. The Application Pool user also should have rights in the virutal folder to read at the least and optionally write if you want to update settings in web.config/wc.ini dynamically through teh admin interface.
The other OS permissions are the temp folder which is important for file based processing - the temp folder needs to have rights for the Application Pool identity so that IIS/Web Connection can read/write temp files from the folder.
FWIW, all of this is automated as part of the Web Connection Configuration/Management Console. If you create a new project/process it'll set all of this up for you. If you have an existing site or need to configure a new site, the Configure Server Wizard will set most of these things for you.
+++ Rick ---
I have read the entire doc file and found it helpful. I have also been in this business for a long time, and have worked on some pretty complex IT installations worldwide in various platforms. Yet I find properly setting up a WC site, with correct security, to be the most confusing and difficult task in my entire career.
Perhaps I can be educated : My sites run on win2003, and each site only allows access to specific users from the server's local user list. No anonymous access allowed even to index.html. There is an administrative user who has admin rights to all sites.
So let's say I have site MySite:
SiteFolder
-- bin folder wit wc.dll/ini
appfolder
myapp.exe is here
-- subfolders with data, etc.
-- the temp folder is also under here
upateFolder
this folder just holds the new exe to be used in updateexe
Let's call the allowed user MyUser. I have given Myuser rights to all the above folders (the admin usre has rights as well, thus 2 users with rights). In IIS I have also given site permission for that same user and of course the admin.
In wc.ini I list as the adminaccount the admin user. I tried adding Myuser as well, but all wc.dll admin functions fail if I do that.
Site and apppool setup OK, windows and basic authentication turned on. Scriptmap set.
The wc site setup can never register the exe itself, so I set up the site manually.
Now comes the tricky part.
1. What IIS permissons, if any, should system, network service, and local service have? To which folders?
2. What server file permissions should those same accounts have and to which folders?
3. In dcomcnfg, I have eveything for the exe set to default except the user under which the exe runs. I have set that to Myuser, the only setting I found to work. What should I be doing in dcomcnfg?
4. In the wc setup it offers to give dcom rights to multiple users. Do I need to do that and where?
5. When I use admin.asp and I do a function, I often get 3-5 prompts for user authentication before the process runs. Each time I am entering the same user. What did I do wrong?
6. How does the impersonation setting in wc.ini fit into any of this?
your kind advice is appreciated.
West Wind Technologies
Making waves on the Web
from Maui, Hawaii