0

I'm integrating with quickbooks desktop via their webconnector. I've done this before, so I'm not completely green, but I'm trying to setup a new application and am having trouble diagnosing the issue. I have my application added to webconnector and authenticated with quickbooks. I've got my application URL properly configured and working, and I have it setup to log server-side anytime it gets hit by anything before it even launches the (server-side) quickbooks handler. This way, I know if the URL is even being called.

When I first add the application it hits the URL to verify the SSL certificate, which it does so successfully, and my server-side logs verify that the server-side application has been called. However, when I try to update the application from inside of quickbooks webconnector, I very immediately get an error with:

QBWC1012: Authentication failed due to the folloowing error message: The request failed with HTTP status 403: Forbidden. See QWCLog for more details. Remember to turn logging on.

This sounds like a server-side error of course, but it isn't: I have verified repeatedly that the application URL is properly configured in the QWC file, that the application URL does not return a 403 under any circumstances, and that the computer itself can reach the application URL (I copied it out of the webconnector file and pasted it into internet explorer).

The QWCLog file seems useless: logging appears to be on (there is a message for log file initialization for today) but nothing gets added to the log file when things run. The log file itself suggests that the log level is set to "DEBUG". Here is the latest entry:

Log file initialized at Tuesday, September 26, 2017 - 1:28 PM UTC  
Timestamp format used: YYYYMMDD.HH:MM:SS UTC
QBWebConnector 2.2 has been initialized with its logging status to level = DEBUG.
Please restart QBWebConnector for any change in log level to take effect. Use file menu to clear log.

20170926.13:28:09 UTC : QBWebConnector.RegistryManager.setUpdateLock() : HKEY_CURRENT_USER\Software\Intuit\QBWebConnector\UpdateLock has been set to False
20170926.13:28:09 UTC : QBWebConnector.RegistryManager.setUpdateLock() : ********************* Update session unlocked *********************
20170926.13:28:09 UTC : QBWebConnector.RegistryManager.setUpdateLock() : HKEY_CURRENT_USER\Software\Intuit\QBWebConnector\UpdateLock has been set to False
20170926.13:28:09 UTC : QBWebConnector.RegistryManager.setUpdateLock() : ********************* Update session unlocked *********************
20170926.13:28:11 UTC : QBWebConnector_Load() : 
QuickBooks Web Connector 2.2.0.71 has started.
Tuesday, September 26, 2017 at 9:28:11 AM
20170926.13:28:11 UTC : QBWebConnector_Load() : QBWC Form Loaded
20170926.13:42:45 UTC : QBWebConnector.RegistryManager.setUpdateLock() : HKEY_CURRENT_USER\Software\Intuit\QBWebConnector\UpdateLock has been set to False
20170926.13:42:45 UTC : QBWebConnector.RegistryManager.setUpdateLock() : ********************* Update session unlocked *********************
20170926.13:42:45 UTC : StopFlexConnector : Object reference not set to an instance of an object.
20170926.13:42:45 UTC : StopFlexConnector :    at QBWebConnector.QBWebConnector.StopFlexConnector()

There is an error in the log file, but it seems to be related to log initialization, and there is certainly nothing specific to my request. There are other applications already installed in webconnector that have ran successfully today, so webconnector itself is working, despite the apparent error in the log file.

To recap my issues that I need help with:

  1. My webconnector application is giving me a '403: Forbidden' error but my application URL is correct and my application only ever returns a 200, and is never called.
  2. The log file doesn't have any information about the problem at all. This could be a sign that the log file is also broken, but I'm not familiar enough with windows permissions (or webconnector's quirks) to know if there is a separate issue or if the logging just sucks.

Any help would be appreciated. Thanks!

Conor Mancone
  • 1,940
  • 16
  • 22

1 Answers1

0

This is a server-side error. Something on your web server is generating 403 Forbidden HTTP errors.

You'll need to fix your web server or script.

If you need additional help, please post the URL and a clean run of the log file, with the Web Connector set to VERBOSE logging mode. It's impossible to troubleshoot further without those additional pieces of information.

Keith Palmer Jr.
  • 27,666
  • 16
  • 68
  • 105
  • The URL is an internal testing site, and so I don't think that posting it here is going to do much good (otherwise I would have included it). Webconnector itself hasn't been to much help either: I actually tried out the "Clear log" command within webconnector to make sure I was looking at the right stuff in the log file but it appears to have no effect: when I tell webconnector the clear the log, I get no errors, no feedback, and the log remains unchanged. I think half of my problem is that QB lives on a window server which I don't manage and don't have real permissions for. – Conor Mancone Sep 26 '17 at 18:55
  • I'll come back and update when I figure out what's going on, but right now I'm very certain that it is not my web server generating the 403 error: I've tested my end of things extensively. I've been wondering if there might be an internal windows or networking setting that would cause it: the network has some extensive filtering/firewalling in place that I am not in control of, but since everything loads fine from the browser, I can't determine for sure where the problem might be. – Conor Mancone Sep 26 '17 at 18:57
  • I can tell you it's not the Web Connector itself for sure. So it's either your web server, or something between you and your web server. I'm not sure how (assuming the URL is using a valid SSL/TLS certificate) anything could be intercepting the encrypted data and fudging the 403 error. It also doesn't sound like your logging is working - that CLEAR LOG button *should* work. – Keith Palmer Jr. Sep 26 '17 at 20:31
  • **sigh** This is what I get for saying trying to make strong assertions about where the issue isn't. I finally remembered to check my (nginx) server logs and sure enough I see the request coming in with a 403 returned ... and I just realized what the problem is... Code igniter puts CSRF protection on all POST requests across the board... time to turn that off... – Conor Mancone Sep 26 '17 at 20:40
  • Thanks, that was it. Sometimes you just need a reminder that friendly reminder that "No really, it's your problem: dig more" – Conor Mancone Sep 26 '17 at 20:55
  • Glad you got it figured out! – Keith Palmer Jr. Sep 27 '17 at 01:49