BigCommerce webhooks not firing + view an active list - api

I'm currently developing with a test store - I'm not sure if that has any relevance.
After successfully creating a webhook (response to being created below), I have been unable to get it to fire.
{
"id": 13300,
"client_id": "d8xgoreoa4qggw30lx7v0locfxoqna7",
"store_hash": "vh2s7g3i",
"scope": "store/order/statusUpdated",
"destination": "https://www.[HIDDEN].com/bigcommerce-api/webhooks/",
"headers": null,
"is_active": true,
"created_at": 1424993422,
"updated_at": 1424993422
}
Questions:
Is it possible to list all active webhooks from within the store management area? EDIT: I am able to request an active list of webhooks through the API, I am curious if it is possible to see these same active hooks within the store management area.
Is it possible to force a webhook to fire? Because updating order status does not seem to be making calls to my destination URL.

To address your questions:
It is not possible to see a list of all active webhooks from within the Control Panel. You can only see that via the API and you can only see webhooks which you created with your API access token and client ID. Other apps installed to the same store who register their own hooks are segregated from yours.
Updating the status of an order is forcing the webhook to fire as the event occurred. There is not a way to trigger the webhook to fire without causing the event tied to the scope of the webhook.
If you are not receiving these webhooks the most likely issues are either the SSL installed at your destination URL is missing Intermediate CAs, or, that your servers are not properly configured for an SNI enabled request.
What to do to test:
Start with the "Troubleshooting" steps seen at the bottom of this page:
https://developer.bigcommerce.com/api/webhooks-getting-started
You can run a test on your domain at the SSL check site mentioned to confirm you have all of your Intermediate CAs and no other obvious errors. Assuming all that checks out the next thing to look at is your server configuration. If you are using a virtual server then you need to make sure that your server is properly configured to accept an SNI protocol message and respond with the proper SSL for your destination URL hostname.
The process of configuring an Apache server to work properly with SNI is as seen here:
https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
This process will differ by server type but generally you need to make sure your vhost configuration is setup properly for your destination URL if you are running a virtual hosted setup. If your server is not setup to use the SNI protocol and is configured incorrectly so your hostname is not in the vhost configuration file (or default SSL config file), then you will not be able to receive webhooks.
If your server is not a virtual server then you just need to confirm that your default SSL configuration file is including your destination URL hostname as part of the default SSL config.
If a request to your destination URL is met with an SSL that does not match your domain in the initial SSL handshake, then the request will not go through.
Let me know if you are still having problems after looking into the above and we will see what else we can test.

Related

DNN LDAP Authentication with DNN.ActiveDirectory

I am having some trouble and need some help. I am trying to connect a website to authenticate to Active Directory through LDAP using DNN.ActiveDirectory, but I can only get the "Check Root Domain" portion to pass. Using ldp.exe on the server I am able to connect to the domain controller and query the users on it with the same user name and password I am trying to use with the plugin, and even using my domain admin account makes no difference. I have tried it with every authentication type, changing the root domain (only way that would get the check root domain to pass is the LDAP://domain.local), with/without the domain in front of the username, and with/without the default domain filled out.
I don't have access to the error logs at the moment since I am not at that office yet, so I will get those posted when I can. If I remember correctly the error being logged was an authentication error. LDAP initially wasn't configured on the domain controller so I had to set that up, and admittedly I am not too familiar with it so I followed this guide: https://techcommunity.microsoft.com/t5/sql-server-blog/step-by-step-guide-to-setup-ldaps-on-windows-server/ba-p/385362. I am using the default ports. I stopped before setting up LDAPS, but when I couldn't get that to work I continued through up to the signing the certificate part. I was working on getting the certificate signed when I came across notes that DNN.ActiveDirectory doesn't support LDAPS. My tests with successful connections using ldp.exe were all against port 389. Are there some extra configurations that are needed to get DNN.ActiveDirectory working that weren't covered in that guide, or any common snags I should be aware of?
DNN.ActiveDirectory has not been maintained for a while, and does not support LDAPS afaik - see Checking Root Domain step fails.
My recommendation is to have a look at AD-Pro Authentication.

Why is my url being modified with my setup?

I have a tt-rss server I host behind a Trafik instance. The host is something like ttrss.example.com and I access it on the web like https://ttrss.example.com. It works just fine anywhere on the internet.
When I try to make a request like
AF
.request(
"\(url)/api",
method: .post,
parameters: ["user": user, "password": password],
encoding: JSONEncoding.default
)
.responseDecodable(of: SessionResponseModel.self) { response in
debugPrint("Response: \(response)")
}
I get an error like
2022-09-29 21:24:36.652181-0400 ttc[89065:7539083] Task <808A492A-D131-448F-ADFD-4EE7158251D9>.<2> finished with error [-1022] Error Domain=NSURLErrorDomain Code=-1022 "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection." UserInfo={NSLocalizedDescription=The resource could not be loaded because the App Transport Security policy requires the use of a secure connection., NSErrorFailingURLStringKey=http://ttrss.example.com:8889/api/, NSErrorFailingURLKey=http://ttrss.example.com:8889/api/, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <808A492A-D131-448F-ADFD-4EE7158251D9>.<2>"
), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <808A492A-D131-448F-ADFD-4EE7158251D9>.<2>, NSUnderlyingError=0x600002b39e60 {Error Domain=kCFErrorDomainCFNetwork Code=-1022 "(null)"}}
As you can see somewhere along the line Alamofire modified my url. Incidentally 8889 is the port my tt-rss server is running at behind Traefik.
My question is: why is Alamofire not just using the url I provide and like... Further resolving the url, but only partially?
I don't think this is an issue with neither tt-rss nor Traefik because both of those things are working just fine on every other part of the internet. There could be some config I am missing in Trafik that Alamofire needs, but beyond that I am not sure what I am doing wrong here.
Edit: I no longer thing this is Alamofire doing this. I believe it's Swift or iOS that's resolving the URL improperly (according to me).
If you read the error, this is an App Transport Security error, meaning the system wasn't able to securely connect based on the default ATS rules. In your case it's because you're not using https at all. You either need to connect using https, or if you can't, enable insecure connections for that domain using the methods indicated in Apple's documentation.

Docusign app getting error this page isn't working right now, local host can't currently handle this request, http error 500

I'm developing an app based on the Docusign C# Quickstart.
Its working fine on my development PC (Win 11) in Visual Studio 2019 using IIS Express.
However, when I publish it to IIS (v10) on my development PC it runs and I can authenticate with Docusign just fine (once I got the proper redirect URI registered: https://localhost/ds/callback) but the step that actually sends the envelope is returning the following error in the browser:
This page isn't working right now.
Local host can't handle this request
http error 500
Any help is appreciated. I logged a support ticket with Docusign, but still waiting for a response.
Quickstart is just an app to show you how to use DocuSign APIs.
The redirect after signing is back to localhost, and your app, once ready to be deployed to server, has to be set with a proper URL, at which point you'll need to update the redirect URI to the one based on your server.
The 500 error is coming from your app, not from DocuSign. You need to figure out why your app cannot handle the URL that is set for redirect after signing by DocuSign.
The base API address demo.docusign.net/restapi is used to reach the development/ test platform. The na4.docusign.net/restapi address is one of DocuSign's (many) production platforms.
Remember that, once you have passed the Go-Live process, you have two Client IDs (integration keys) one for the test platform, one for all of the production platforms. Each has its own settings.
Added
The error
This page isn't working right now.
Local host can't handle this request http error 500
Is from IIS. Use IIS logging to see the URL request that is coming in that can't be handled.
To see if it is the redirect from the initial OAuth Authorization Code grant URL, examine the initial URL redirect to account.docusign.com (prod URL).
The redirect contained as a query parameter in the initial OAuth redirect must:
Be correct for your instance of IIS.
Be allowed by your setting for the client ID (integration key) in DocuSign
1, Be properly handled by your IIS and its app.

Possible proxy issue with WSO2 API Manager

Whenever I try to add the following endpoint, "http://ws.cdyne.com/phoneverify/phoneverify.asmx", during the Managed API setup process and press the Test button I get an error on the server. ERROR - APIProviderHostObject Error occurred while connecting to backend : "stackOverflow preventing me from showing this link", reason: Connect to ws.cdyne.com:80 timed out
When I try this exact same process on a machine outside of our proxy it works fine. I have gone into the axis2.xml file and added proxy information and even went as far as installing cntlm and setting the proxy to localhost - same error.
I can browse to the above link just fine on this machine.
My environment is Windows 10.
I assume you talk about clicking the Test button when providing Backend Endpoint in API publisher.
The way that Test button works at the moment (as far as I understand) is that it invokes HTTP HEAD method on the endpoint provided (because according to RFC 2616, "This method is often used for testing hypertext links for validity, accessibility, and recent modification.")
Then it checks response. If response is valid or 405 (method not allowed), then the URL is marked as Valid.
Thus sometimes, if backend is not properly following RFC, you might get otherwise working URLs declared as Invalid during the test because of that improper HEAD response evaluation. Obviously, this is just a check for your convenience and you can ignore the check if you know the endpoint works for the methods and resources you need it to work.
So my advice would be to try ignoring the Test and just finishing setting up and publishing the API.
P.S. I am checking it on WSO2 API Cloud but behavior is identical to downloadable API Manager.

Configuring a custom port for the 'localhost' redirect URL in Google OAuth 2.0

I want to configure a custom port for the redirect URL in the Google Developer Console for the class of 'Installed Apps'.
Following the instructions in https://developers.google.com/accounts/docs/OAuth2InstalledApp , it turns out that this should be possible:
redirect_uri=http://localhost:9004&
Going to the Console ("console.developers.google.com"), "Credentials", and "Create New Client Id", I cannot find the field, where to enter a custom port number. Does anyone know how to do this?
Thanks!
In fact, The document you've read has answered you question:
When you create a client ID in the Google Developers Console, two redirect_uris are created for you: urn:ietf:wg:oauth:2.0:oob and http://localhost. The value your application uses determines how the authorization code is returned to your application.
http://localhost signals to the Google Authorization Server that the authorization code should be returned as a query string parameter to the web server on the client. You may specify a port number without changing the Google Developers Console configuration.
I tried this idea and it works.
Give consecutive ports or probable ports in credentials as
**Redirect URIs**
http://localhost:55738/YoutubeVideoList.aspx
http://localhost:8080/YoutubeVideoList.aspx
http://localhost:8081/YoutubeVideoList.aspx
http://localhost:8082/YoutubeVideoList.aspx
http://localhost:8083/YoutubeVideoList.aspx
http://localhost:8084/YoutubeVideoList.aspx
and don't forget to give correct redirectURI with port(anyone above) while calling the authentication process.