08:34:37 AM
3KF0IDVQ0
Why are you converting from UTF-8 to DBCS to codepage? Why not work with Unicode? using unicode with WC is described here http://www.west-wind.com/presentations/foxunicode/foxunicode.asp
Rick,
FoxInCloud uses the basics of wconnect: mainly the Base classes, wwSession, wwConfig, West Wind Internet Protocols, wwUtils, wwAPI
On top of those you identified, migration issues are:
- figure out where we use DEBUGMODE and make sure we always have a reference to the server to replace by Server.lDebugMode
- make sure our error handling process still works within a TRY ... CATCH
- figure out where we modified the code throughout the framework (sometimes because lazy to sub-class, some changes in procedures or functions like in wwUtils)
- fix the URLdecode() issue on double-byte UTF-8 encoding, e.g.
? URLdecode('aff%C3%BBteuse') && renders 'affûteuse' instead of 'affûteuse'
We sent you a PM about this issue on Mon, 02 Apr 2012 19:13:51 +0200, with a test case to reproduce it;
Did you receive this email?
This issue is the most critical - if we move to WC5 without a WW fix in wwUtils and wwIPstuff.dll, we fear FiC clients will update their WC5 package and overwrite the fix we wrote in wwUtils!URLdecode().
FWIW, here is our version of wwUtils!URLdecode()
************************************************************************ FUNCTION URLDecode ****************** *** Function: URLDecodes a text string to normal text. *** Assume: Uses wwIPStuff.dll *** Pass: tcText - Text string to decode *** Return: Decoded string or "" && {V 1.11} Modified by Abaque FoxInCloud to support double-byte UTF-8 encoding ************************************************************************ LPARAMETERS tcText tcText = Strtran(m.tcText, '%25', '%') && looks like '%' are encoded *** Use wwIPStuff for large buffers IF .F. && Len(m.tcText) > 10000 && {V1.11} wwIPstuff.dll!URLdecode() has an issue with utf-8 double byte characters such as 'û' DECLARE INTEGER URLDecode IN WWIPSTUFF AS API_URLDecode ; STRING @tcText LOCAL lnSize lnSize = API_URLDecode(@tcText) RETURN Iif(m.lnSize > 0; && /!\ Abaque , Strconv(Strconv(Leftc(m.tcText,m.lnSize), 11), 2); && UTF-8 > double byte > single byte dans le "Locale ID" du système , ''; ) ELSE *** First convert '+' to spaces tcText = Strtran(m.tcText, "+", " ") #IF wwVFPVersion < 8 loEval = CREATEOBJECT("wwEval") #ENDIF LOCAL lnLoc, lcHex, lnHex, lnHex2, lcDouble, llDouble, lnDouble, loEval, lcResult lcResult = "" DO WHILE .T. *** Format: %0A (CHR(10)) lnLoc = At('%', m.tcText) *** No Hex chars - just return the text IF m.lnLoc < 1 OR m.lnLoc > Len(m.tcText) - 2 lcResult = m.lcResult + m.tcText EXIT ENDIF *** Now read the next 2 characters *** Check for digits - at this point we must have hex pair! lcHex = "0x" + Substr(m.tcText, m.lnLoc+1, 2) lnHex = -1 #IF wwVFPVersion < 8 loEval.vErrorResult = -1 lnHex = loEval.EVALUATE(m.lcHex) #ELSE TRY lnHex = Evaluate(m.lcHex) CATCH ENDTRY #ENDIF IF lnHex > -1 lcHex = Chr(m.lnHex) * If another '%xx' sequence follows, try a souble-byte UTF-8 encoding llDouble = .F. IF Substr(m.tcText, m.lnLoc+3, 1) == '%' lnHex2 = -1 TRY lnHex2 = Evaluate('0x' + Substr(m.tcText, m.lnLoc+4, 2)) CATCH ENDTRY IF m.lnHex2 > -1 lcDouble = Strconv(Strconv(m.lcHex + Chr(m.lnHex2), 11), 2) llDouble = Len(m.lcDouble) == 1 AND Asc(m.lcDouble) > 128 lcHex = Iif(m.llDouble, m.lcDouble, m.lcHex) ENDIF ENDIF *** Concat the string plus the evaled hex code lcResult = m.lcResult + Left(m.tcText, m.lnLoc - 1) + m.lcHex *** Trim out the input string lnDouble = Iif(m.llDouble, 3, 0) IF Len(m.tcText) > m.lnLoc + 2 + m.lnDouble tcText = Substr(m.tcText, m.lnLoc + 3 + m.lnDouble) ELSE EXIT ENDIF ELSE * Skip over lcResult = m.lcResult + Left(m.tcText, m.lnLoc) tcText = Substr(m.tcText, m.lnLoc + 1) ENDIF ENDDO RETURN m.lcResult ENDIF ENDFUNC * EOF URLDecode
Regards,
Thierry,
Well, I'm not sure what FIC actually does on the Web Connection integration level, but it seems to me changes required to go to 5.0 for you should be minimal - there are only a few things that are required (mainly changing the error handling mechanism, Init code handling and wwProcess routing).
Here's the help topic tree:
Upgrading from Version 4.0
Most of these things likely don't even apply to you. All you likely have to change is your process main class implementation...
The reason it's important to use V5 IMHO is that there have been many improvements in the isapi and .NET modules (which works better for IIS 7), many core VFP framework fixes, and we continue to update these versions to address issues and security as well as deployment.
In the long run this should make your life much easier for a little dev time updating. As it stands right now it's hard for me to even look at problems your customers might have because they'll are running a 7+ year old version. I'll be happy to look at and fix any Web Connection 5 problems, but v4? Not so much and often the answer is - it's been fixed in 5.0.
+++ Rick ---
Rick, Tuvia
FoxInCloud is based on previous developments started in V 4.0.
Migration to V5 is indeed part of FoxInCloud roadmap.
Given the upgrading issues from V4 to V5, we just gave a priority to improving FAS rather than migrating so far.
FoxInCloud clients all having a V5 license, they can use the V5 console to setup their sites and applications.
Nothing in developing an application in V4 makes this process more complicated or even different; the VFP COM server reacts exactly the same.
Thanks,
Tuvia,
First off you're using an at least 7 year old version of wc.dll if you're using a 4.x based version. Lots has been changed and fixed since then. :-) While I understand that's a requirement for FIC that's a long stretch for me to check into, and I can't help but think that FIC made a bad decision in sticking with the 4.x version when they created FIC when 5.x was already avalailable for some time - they basically locked themselves out of any upgrades and fixes that we provide for both the core and framework.
Ok, so I have not seen any of the behavior you describe nor have I ever heard complaint from anyone else about this - that doesn't mean it's not real, but it does seem to suggest something out f the ordinary is happening on your setup. If you can provide me with repro steps that I can check out on my end I'll be happy to take a look and fix it if there is a problem in a recent version of Web Connection.
What I do know is that there are multiple auth schemes involved (Windows Auth for the main admin page, and Basic for Web Connection Requests) for admin authentication, which can cause at least two logins. But once you're logged in either of these auth schemes should stick unless you're doing some crazy stuff in multiple browser windows.
+++ Rick ---
1. Frequently calling any management function from wc.dll gives an invalid admin account error for no reason.
2. UpdateExe does not work (nor give an error - it pretends to work) on some sites. the only thing I can find in common within those sites is they have no anonymous user even listed under security.
3. Sometimes when accesiing a wc.dll management function from wc.dll I have to authenticate 2 or more times from one call.
4. Even if UpdateExe works on a site, neither it nor any wc.dll management call works when called propeprly from wwhttp.httpget.
5. If two or more administrators are listed in wc.ini, then sometimes no login will work (invalid login error) or the authenticated name is truncated by 1 character.
Well, if you don't know what it IIS Impersonation is, it's unlikely you set it :-) There's a setting in ApplicationHost.config that determines how the virtual handles authentication. Yes it's set in web.config or ApplicationHost.config but the latter is the main IIS configuration store.
>BTW, all the sites that use an app pool share the use of it via one user's login. So the only way to set the app pool user identity is to give it an admin level user. There is no way specify by site, just for the entire app pool no matter what site uses it. Using that as the main security user would be a disaster. IIS permissions for folders need to be coupled with server OS permissions for the site to work at all.
That's why you can create multiple app pools, so you can isolate each application. Not really sure why this matters though - if you have an admin account and that account really has full access to the system then it should just work. As should SYSTEM which is the Web Connection default.
> Basically I do not understand what it is you are trying to tell me.
Basically I do nto understand what it is that you're asking since you're telling me several issues that may or may not be related.
+++ Rick ---
+++ Rick ---
I was describing how it is working; I did not mean I thought it should work that way.
In the site security settings, I disable the "allow anonymous user" checkbox. I searched the help system and my friendly iis admin book and could find no reference to the setting you describe or even to the word impersonation except for asp.net, which we do not use.
BTW, all the sites that use an app pool share the use of it via one user's login. So the only way to set the app pool user identity is to give it an admin level user. There is no way specify by site, just for the entire app pool no matter what site uses it. Using that as the main security user would be a disaster. IIS permissions for folders need to be coupled with server OS permissions for the site to work at all.
Basically I do not understand what it is you are trying to tell me.
If there is an anonymous user in existance, even with rights only to a home non-wc page, then the app pool will run under local system. If there is no anomymous user, the apppool must have administrator level rights.
What? No.
If you don't want anonymous authentication to work turn it off in IIS. No matter what you do then no anonymous user will ever get passed through.
Based on what you're describing it sounds like you might have your IIS virtual or root configured to use Impersonation - rather than Application Pool based identity. With Impersonation the logged in user gets rights on the server (which is very, very bad!). Make sure you don't have this enabled in IIS - I don't recall how this gets set in IIS 6, but there's an option for it presumably on the security tab for the site/virtual.
+++ Rick ---
Thank you for the succint explanation. I think I understood that much, but it never works without more fiddling. The config console (at least in 4.x) seems to only create virtual or sub-sites, all my sites are top level sites in IIS.
Perhaps an example based on your description:
They break down like thi. the server has 20 sites all sharing one application pool. The app pool identity is set to local system.
now for site Site1:
dcom is set to an administrator level user.
OS does NOT have the anonymous user, I want anyone hitting the site to have to login.
Frankly, I think that last thing of no anonymous user is what is causng me many problems.
One thing that makes me think that, is that even if the dcom, iss, ad os are all set as administrators, the site will not run without SYSTEM having rights. BUT if I have an anonymous user that can hit the site main page at least, everything runs fine with no SYSTEM user and administrator rights.
Still, with all the admin rights, i often get invalid admin user account when doin things like re-read configuration. But sometimes not.
HOLD ON, just discovered the problem of the updateexe and some others, although still getting errors on some things like re-read config.
Here it is:
If there is an anonymous user in existance, even with rights only to a home non-wc page, then the app pool will run under local system. If there is no anomymous user, the apppool must have administrator level rights.
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.
- 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.
