If you have a valid cert you want that false anyways.
Set it to false if you are cloud you have a valid cert
I just changed it and it looks like we have success. Memory held static across 5 different calls. Iâm going to publish and monitor it tomorrow when we typically see the exceptions to confirm.
Iâm wondering if we should pull that out at this point. At time of development that was key to making this work in a lot of cases, but especially with the move to kinetic you pretty much have to figure out how you want to present a valid cert, of which there are many free or nearly free ways of doing it now.
Itâs a nice option to have for anyone who has an on-site dev environment. You generally donât purchase a cert for a dev box. The option should do nothing when a valid cert is present. The fact that the behavior changes when there is a valid cert is a bug.
Itâs a call configuration for javascript (or I suppose for the nuget c#, but we use the same logic in the NPMs too), until the call is made you wouldnât know if you had a valid cert to ignore the flag. Itâs a chicken and egg.
Many free means of having a valid cert that is auto renewed even. All our servers run valid certs 0$ cost.
@Mark_Wonsil the security curmudgeon would also argue you should have verified secure traffic on your dev servers too. Unless youâre using the demo DB youâre still passing your real data although it may be older.
To avoid the chicken egg you describe I would try it normally and catch the invalid cert error. If the ignore flag is true we would set the flag on the next request and try again. This double request is a good compromise if youâre going to default assume the cert is valid anyways.
I am also a security curmudgeon but I would argue that the traffic is still encrypted and verified secure because Iâm the one who generated the cert. Itâs not invalid to me.
The option is a liability if used incorrectly. Given itâs easy to obtain valid certs these days I just donât see the need for it. It was put there for us to do some Excel magic years ago on v1. I think itâs just outlived its usefulness. What is the aversion to setting up proper certs?
What I do for DEVELOPMENT only (which is appserver and SQL Server on the same Hyper-V instance)
Create a fake domain in my host file:
Create a self-signed certificate using PowerShell using the hostname above:
New-SelfSignedCertificate -DnsName "k2021.erptest.dev" -CertStoreLocation cert:\LocalMachine\My -FriendlyName "k2021.erptest.dev" -NotAfter (Get-Date).AddYears(10)
Open the Cert snap in, copy the cert from Personal | Certificates
and paste into Trusted Root⌠| Certificates
Export the cert:
Next, I go to the IIS snapin and import the cert
That should eliminate any SSL errors in your WIndows environment using Chrome-based browsers.
Edge:
Chrome
To use Postman, enable SSL verification at the program level. It will not work at the request level.
and import the cert:
Again, this is for DEVELOPMENT only. Iâm not using company data. A Pilot, Staging, or Test server gets set up exactly like Production.
Iâm not too sure what exactly in the code is causing the issue⌠The standard way of ignoring cert validation errors in C# is pretty foolproof, you just override the callback delegate to always return true.
ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) => true;
I would be sad to see the option go, even though I am still using 2.0.4 for sync calls at the moment⌠Although theoretically you should be able to add that line to the calling code and it should just work, unless some weird stuff is being done in the called code.
Thatâs what it does but aparently there is a memory leak in that implementation
I say leave it alone
Iâve asked about this cancelation token implementation several times in my code posts earlier. If thatâs unrelated or not applicable then Iâll shut upâŚ
Hmmm, this seems very useful but am hitting errors
I setup my config and followed one of the simpler examples provided to download packages and setup config:
EpicorRest.AppPoolHost = ââŚepicorsaas.comâ;
EpicorRest.AppPoolInstance = âsaasâŚâ;
EpicorRest.UserName = âmyUserNameâ;
EpicorRest.Password = âmyPasswordâ;
EpicorRest.APIKey = âmyApiKeyâ;
EpicorRest.Company = âOFBâ;
EpicorRest.APIVersion = EpicorRestVersion.V2;
EpicorRest.IgnoreCertErrors = true;
EpicorRest.Timeout = 5000;
For this test
var res = EpicorRest.BaqGetDataTable(âRestTestâ);
I get âProblem getting BAQ Mata Data Errorâ
For this test
response = EpicorRest.BoGet(âIce.BO.AdminSessionSvcâ, âGetSessionListâ, null, callContext);
I get âAn error occurred while sending the request.â in the response
datadaddy: did you resolve the âproblem getting baq metadata errorâ? I am running into it also
No, I had to give up, was hoping for more ideas from the experts here
I believe the BaqGetDataTable method was originally implemented in V1 but I donât think it has been updated since. I can take a look at it we pivoted pretty hard into Generic calls that can be manipulated by you instead of us giving you pre-determined output (like a data table) because the generic output is generally more useful and flexible.
You can generate your own table from the BAQ Results.
I think I have tracked down my problem: our epicor installation uses windows authentication so I donât have usernames and passwords for epicor itself. Is there a way to utilize windows authentication using EpicorRestAPI?
Yeah, I think Jose does it here: