View previous topic :: View next topic |
Author |
Message |
dklewe
Joined: 17 May 2017 Posts: 13
|
Posted: Wed May 17, 2017 4:05 pm Post subject: PageGate v7 Web Interface |
|
|
I am trying to setup the web interface for PageGate. I have followed the instructions in the support section. The client page loads when I use the URL, server followed by the group name. http://<SERVER>/pgweb
When I select the recipient, enter some text, and click send, the browser tab says waiting for <server>. If I look in the task manager, an instance of webgate32 is started and runs at 100% indefinitely. The page is not sent. The same recipient does work from the thick client.
|
|
Back to top |
|
Tech Support
Joined: 25 Aug 2003 Posts: 4356
|
Posted: Wed May 17, 2017 4:09 pm Post subject: |
|
|
That indicates that the user/usergroup on the workstation where it isn't working doesn't have sufficient permissions to the CGI data directory that the webgate.exe lives in. You'll want to go in to the properties of that folder on the web server, go under the Security tab and set that user/usergroup to have the Read and Execute permission. |
|
Back to top |
|
dklewe
Joined: 17 May 2017 Posts: 13
|
Posted: Wed May 17, 2017 4:23 pm Post subject: |
|
|
Per the instructions, I added the Domain Users group to the "scripts" directory and changed the permissions to modify. Read and execute are also checked.
As a test, I can type the network path to the file from another PC and launch the exe to a shell.
For example, \\<server>\c$\intetpub\scripts\webgate.exe
This executes the file in a shell.
|
|
Back to top |
|
Tech Support
Joined: 25 Aug 2003 Posts: 4356
|
Posted: Thu May 18, 2017 7:55 am Post subject: |
|
|
Hm... that's peculiar and makes me wonder what the difference is between the workstations that are allowed to submit the information to our CGI executable and which aren't. In instances like this, where one machine can but another can't, it usually comes down to a permissions or directory access issue on the web server hosting the CGI executable.
So, in practice, what are the differences between the logons of the 'thick client' that you mentioned and the workstation where the submission isn't being allowed to happen? |
|
Back to top |
|
dklewe
Joined: 17 May 2017 Posts: 13
|
Posted: Thu May 18, 2017 9:24 am Post subject: |
|
|
It's the same machine, with the same login. Same result when I try from a remote workstation or directly on the server, all with the same admin login.
|
|
Back to top |
|
Tech Support
Joined: 25 Aug 2003 Posts: 4356
|
Posted: Thu May 18, 2017 9:28 am Post subject: |
|
|
Just to dot some i's and cross some t's, in the settings of GetWeb, what do you have set for the web pages path, CGI data path and CGI URL fields?
Also, is the web server using Apache, IIS, etc? |
|
Back to top |
|
dklewe
Joined: 17 May 2017 Posts: 13
|
Posted: Thu May 18, 2017 9:38 am Post subject: |
|
|
GetWeb settings:
Web Pages Path: c:\inetpub\wwwroot\
CGI Data Path: c:\inetpub\scripts\
CGI URL: http://<ServerName>/scripts/webgate.exe
Using IIS on the same server.
|
|
Back to top |
|
Tech Support
Joined: 25 Aug 2003 Posts: 4356
|
Posted: Thu May 18, 2017 9:41 am Post subject: |
|
|
There are a few things I'd like to check in the IIS Admin. If you would, open that and select the server object (first item in the left hand tree). On the right hand side, open the Handler Mappings. Once there, right click on CGI-exe and select "Edit Feature Permissions". Is execute checked?
Back in the main server object, if you open the ISAPI and CGI Restrictions, have you added an entry for PageGate's CGI executable (webgate.exe) and allowed it to execute?
Also, does the scripts directory exist as a virtual directory under your default web server? |
|
Back to top |
|
dklewe
Joined: 17 May 2017 Posts: 13
|
Posted: Thu May 18, 2017 9:47 am Post subject: |
|
|
Yes, all the above appear to be in order. I configured each of these settings as part of the installation procedure for Server 2012.
|
|
Back to top |
|
Tech Support
Joined: 25 Aug 2003 Posts: 4356
|
Posted: Thu May 18, 2017 9:50 am Post subject: |
|
|
Hm... this is getting peculiar. If CGI is allowed to execute and you've specified the webgate.exe in the ISAPI and CGI restrictions, IIS has been configured to allow the CGI parameters to be passed through, provided the user doing the submission has sufficient rights to the folder. What's doubly peculiar is that you're not getting a returned error like a 405 or a 1004 or anything, really. That means that the submission isn't actually being allowed to make it to the CGI executable in the first place, that's the only reason you wouldn't get a proper error in return.
So, question is, what's preventing those variables from being submitted? You've mentioned that the domain users group has the read and execute and modify permissions, so that should allow anyone part of that user group to submit the messages. I wonder, though... if you would, add IUSR to the security section of the scripts folder and allow it read and execute and modify as permissions. |
|
Back to top |
|
dklewe
Joined: 17 May 2017 Posts: 13
|
Posted: Thu May 18, 2017 10:12 am Post subject: |
|
|
When I click send from the web GUI, the server does launch webgate.exe, I can see it pop up in the task manager. At that point webgate.exe quickly ramps to 100% CPU and stays there until I end the task. I've let this go for up to 10 minutes with no change. Meanwhile the browser sits waiting on the server until the task is ended.
|
|
Back to top |
|
Tech Support
Joined: 25 Aug 2003 Posts: 4356
|
Posted: Thu May 18, 2017 10:20 am Post subject: |
|
|
This may seem a bit odd but, if you would, try this:
1) In Windows, browse in to c:\inetpub\
2) Create a new directory: pgscript
3) In IIS, add pgscript as a virtual directory under your default web site.
4) In the PG Admin, go to Interfaces - GetWeb - Settings.
5) Update the CGI data path to: c:\inetpub\pgscript\
6) Update the CGI URL to: http://<yourwebserverhere>/pgscript/webgate.exe
7) Click Apply.
8) Back in the IIS Admin, open ISAPI and CGI Restrictions and edit the entry you have, updating the path to c:\inetpub\pgscript\
9) Go in to the properties of the new pgscript folder and go under the security tab.
10) Add IUSR and Domain Users to have read, execute, modify.
11) Add Domain Admins to have Full Control.
Now we need to force PageGate to re-build the webpages to use the new CGI URL and path:
1) Back in the PG Admin, go in to the Members sub-section of your paging website's group.
2) Remove someone from the group.
3) Add that person right back in to the group.
4) Click Apply.
Note: Any time you modify the member list of a web paging group, PageGate republishes the index.htm and default.htm of that paging website based on the template tied to the group.
Then give it another try and let me know if it works with the new location. |
|
Back to top |
|
dklewe
Joined: 17 May 2017 Posts: 13
|
Posted: Thu May 18, 2017 10:20 am Post subject: |
|
|
After adding IUSR to the scripts folder, the process completes. I get the webpage that says "message accepted", but I don't receive the page or email that should go out for the recipients. These recipients do work as expected from the thick client.
|
|
Back to top |
|
Tech Support
Joined: 25 Aug 2003 Posts: 4356
|
Posted: Thu May 18, 2017 10:22 am Post subject: |
|
|
Ah! Okay, since adding the IUSR to the security descriptors worked, you can disregard my previous post.
Now that we have the messages being submitted, if you go in to the c:\inetpub\scripts\ folder, what files do you see listed there?
Also, if you run the PageGate Monitor, is GetWeb red or green? |
|
Back to top |
|
dklewe
Joined: 17 May 2017 Posts: 13
|
Posted: Thu May 18, 2017 10:25 am Post subject: |
|
|
tmp1.new
tmp2.new
unique.ndx
webgate.exe
webgate.usr
GetWeb is green in the monitor.
|
|
Back to top |
|
|