Using the older version I was able to authenticate using SimpleAuthenticator which took parameters for usernameKey and passwordKey. Starting v107 SimpleAuthenticator was dropped. How can I set these values using http parameters
Related
I would like to upgrade a macOS application I built to allow users to directly download their transaction statements via OFX data direct connect.
So far, my research has found two good sources of info
OfxTools: https://ofxtools.readthedocs.io/en/latest/index.html
OfxHome: https://www.ofxhome.com/index.php/home/ofxget
I've downloaded and installed both (command line from OfxHome and Python from OfxTools). Then tried to download statements from two of my accounts (TD Ameritrade and Fidelity). Both failed.
TD Ameritrade fails with "Signon Invalid"
Fidelity fails with "Access Denied" cannot access from this server
I initially thought the issue is that I am overseas and running from my own computer. So I installed the same two packages on a hosted server running out of San Francisco. Yet, both failed with the same errors.
I happen to be a member of an application (Profit.ly) that allows you to download your transaction statements (they use OFX, just like Quicken, etc). I can enter my TD Ameritrade and Fidelity credentials on Profit.ly, and it can download my transaction data successfully.
So what am I missing? Below is my request from OfxHome cmd line for fidelity.
./ofxget -institution 449 -request accounts.txt
OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:20221211035100.000
<OFX>
<SIGNONMSGSRQV1>
<SONRQ>
<DTCLIENT>20221211035100.000
<USERID>MyUserName
<USERPASS>MyPassword
<LANGUAGE>ENG
<FI>
<ORG>fidelity.com
<FID>7776
</FI>
<APPID>QBW
<APPVER>1800
</SONRQ>
</SIGNONMSGSRQV1>
<SIGNUPMSGSRQV1>
<ACCTINFOTRNRQ>
<TRNUID>20221211035100.000
<CLTCOOKIE>1
<ACCTINFORQ>
<DTACCTUP>19691231
</ACCTINFORQ>
</ACCTINFOTRNRQ>
</SIGNUPMSGSRQV1>
</OFX>
Fidelity Response
<HTML><HEAD>
<TITLE>Access Denied</TITLE>
</HEAD><BODY>
<H1>Access Denied</H1>
You don't have permission to access "http://ofx.fidelity.com/ftgw/OFX/clients/download" on this server.<P>
Reference #18.65f466ab.1670748661.20bf6f3d
</BODY>
</HTML>
TD Ameritrade OFX request
OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:20221211040449.000
<OFX>
<SIGNONMSGSRQV1>
<SONRQ>
<DTCLIENT>20221211040449.000
<USERID>MyUserName
<USERPASS>MyPassword
<LANGUAGE>ENG
<FI>
<ORG>ameritrade.com
<FID>5024
</FI>
<APPID>QBW
<APPVER>1800
</SONRQ>
</SIGNONMSGSRQV1>
<INVSTMTMSGSRQV1>
<INVSTMTTRNRQ>
<TRNUID>20221211040449.000
<CLTCOOKIE>4
<INVSTMTRQ>
<INVACCTFROM>
<BROKERID>ameritrade.com
<ACCTID>MyAcctNumber
</INVACCTFROM>
<INCTRAN>
<DTSTART>19000101
<INCLUDE>Y
</INCTRAN>
<INCOO>Y
<INCPOS>
<DTASOF>20221211040449.000
<INCLUDE>Y
</INCPOS>
<INCBAL>Y
</INVSTMTRQ>
</INVSTMTTRNRQ>
</INVSTMTMSGSRQV1>
</OFX>
TD Ameritrade Response
OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:20221211040449.000
<OFX><SIGNONMSGSRSV1><SONRS><STATUS><CODE>15500</CODE><SEVERITY>ERROR</SEVERITY><MESSAGE>Signon invalid</MESSAGE></STATUS><DTSERVER>20221211040450</DTSERVER><LANGUAGE>ENG</LANGUAGE><FI><ORG>ameritrade.com</ORG><FID>5024</FID></FI></SONRS></SIGNONMSGSRSV1><INVSTMTMSGSRSV1><INVSTMTTRNRS><TRNUID>20221211040449.000</TRNUID><STATUS><CODE>15500</CODE><SEVERITY>ERROR</SEVERITY><MESSAGE>pr-txlvofx-pp02-clientsys Signon invalid</MESSAGE></STATUS><CLTCOOKIE>4</CLTCOOKIE></INVSTMTTRNRS></INVSTMTMSGSRSV1></OFX>
Why can I not use my own computer with my own bank and credentials to download my data via command line using ofxtools or ofxget?
Is there some sort of authorization token, SSL cert, or something I am missing?
Is there a list somewhere of servers that banks trust to fetch OFX data?
Am I asking the wrong questions? lol
Possible deprecation: OFX merging with FDX (https://financialdataexchange.org/ofx)
Update
I got TD Ameritrade to response successfully by changing the APPID and APPVER
From
<APPID>QBW
<APPVER>1800
To
<APPID>MDNC
<APPVER>2021
Using OfxHome commands, I was able to fetch my TD Ameritrade transaction data however, still stuck on Fidelity.
This raises a bigger issue, which is probably core to the whole OFX thing. I'm trying to test OFX data fetching by using two brokers that I have. Straight off the bat I ran into problems and have spent all day just to figure out how to get one broker working. This is not scalable.
I guess the core of the problem is to find a database that contains the most update-to-date data for all the financial institutions. Then, be able to read the database, parse the data into the correct OFX format (w/ correct tags, version #, data), then send the request. This is the most challenging part.
I've reviewed 5 OFX libraries and tested 3 of them. All failed out-of-the-box to format a proper OFX request for TD and Fidelity. After hours of work I was able to piece together what is required by TD.
So the question is
Who has the most updated OFX request data for each financial institution?
Code to compile the OFX data into a proper request for each OFX version
I upgraded from a very old version of the shopify_app (7.2) to the most recent: 18.1
In my "shops" SQL table I have an "api_token" column with the access token for each shop, on the new version the token must be in the "shopify_token" column, so I just copied the "api_token" strings to the "shopify_token" column:
UPDATE shops SET shopify_token = api_token;
but now when I try to start a new session:
session = ShopifyAPI::Session.new(domain: shopify_domain, token: shopify_token,
api_version: ShopifyApp.configuration.api_version)
ShopifyAPI::Base.activate_session(session)
I'm getting an "unauthorized" message, if I use the same access token on the previous version all works fine, so, what changed? how can I make the access tokens work with the new shopify_app gem version?
I found all this situation weird: the token is a mathematical thing, it should work on any shopify_app version.
We're upgrading the version of RestSharp that we use in order to gain support for .NET Core.
Old version is 105.2.3, new version is currently 106.4.0 (but the following applies equally to the latest RestSharp code on GITHub)
Given the following code:
var request = new RestRequest("/webacs/api/v1/data/{reportType}.json?.full=true&collectionTime=ge({collectionTime})&.firstResult={firstResult}");
request.AddParameter("reportType", "HistoricalClientTraffics", ParameterType.UrlSegment);
request.AddParameter("collectionTime", 1497722400000, ParameterType.UrlSegment);
request.AddParameter("firstResult", 0, ParameterType.UrlSegment);
Using RestSharp 105.2.3, when the request is executed (GET) all three UrlSegment parameters cause token substitution to occur and produce a URL like this:
/webacs/api/v1/data/HistoricalClientTraffics.json?.full=true&collectionTime=ge(1497722400000)&.firstResult=0
Using RestSharp 106.4.0 (and also the latest RestSharp source from GITHub) only subsitutions of tokens prior to the '?' occur.
Substitutions beyond the '?' no longer occur and a faulty URL is produced:
/webacs/api/v1/data/HistoricalClientTraffics.json?.full=true&collectionTime=ge(%7BcollectionTime%7D)&.firstResult=%7BfirstResult%7D
(7B and 7D are the ASCII codes for '{' and '}' respectively)
Is this change of behaviour 'by design'?
(It's easy-enough to work around the issue by performing your own token substitutions explicitly)
It is indeed by design. Although technically URL also includes the query, RestSharp is closer to the WebAPI semantics. UrlSegment can be seen as the counterpart of FromRoute and QueryParameter - of FromQuery.
So, when you have the URL http://blah.com/customers/{customerId} and use the following code:
request.AddUrlSerment("customerId", "123");
request.AddQueryParameter("foo", "bar");
it will produce a request to http://blah.com/customers/123?foo=bar.
With Mule Salesforce Connector using sfdc:create, the document says we can send up to 200 records at a time (single round trip call). If that's the case, what benefit do we get using Mule Batch flow with Batch Commit and Salesforce (sfdc:create) within the Batch Commit?
Example create below.
<xml<sfdc:create type="Account">
<sfdc:objects>
<sfdc:object>
<Name>MuleSoft</Name>
<BillingStreet>I live here </BillingStreet>
<BillingCity>My City</BillingCity>
<BillingState>MA</BillingState>
<BillingPostalCode>32423</BillingPostalCode>
<BillingCountry>US</BillingCountry>
</sfdc:object>
.......200 such objects
</sfdc:objects>
</sfdc:create>
Please keep in mind that in Salesforce, the SOAP API Call Limit for a client application is up to 200 records in a single create() call. If a create request exceeds 200 objects, then the entire operation fails.
Please refer reference from Salesforce.
I am getting the following exception whenever i try to fetch defects from rally:
com.google.gson.JsonSyntaxException:
com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 12
at com.google.gson.JsonParser.parse(JsonParser.java:65)
at com.google.gson.JsonParser.parse(JsonParser.java:45)
at com.rallydev.rest.response.Response.<init>(Response.java:25)
at com.rallydev.rest.response.QueryResponse.<init>(QueryResponse.java:16)
at com.rallydev.rest.RallyRestApi.query(RallyRestApi.java:168)
at Test.main(Test.java:86)
Caused by: com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 12
at com.google.gson.stream.JsonReader.syntaxError(JsonReader.java:1505)
at com.google.gson.stream.JsonReader.checkLenient(JsonReader.java:1386)
at com.google.gson.stream.JsonReader.doPeek(JsonReader.java:531)
at com.google.gson.stream.JsonReader.peek(JsonReader.java:414)
at com.google.gson.JsonParser.parse(JsonParser.java:60)
... 5
What intrigues me most is the code works perfectly fine on few machines and throws the above exception on few.
code snippet :
RallyRestApi restApi =
new RallyRestApi(new URI("http://rally1.rallydev.com"),apiKey);
QueryRequest queryRequest = new QueryRequest("defects");
queryRequest.setFetch(new Fetch("Project","FormattedID","Release"));
QueryFilter filter1 = new QueryFilter("FormattedID", "=", defetctID);
QueryResponse queryResponse1 = restApi.query(queryRequest);
Try a curl command to read the same defect using the same apiKey (in zsessionid header) on the same machine from which your java code fails.
curl --header "ZSESSIONID: _abc123" "https://rally1.rallydev.com/slm/webservice/v2.0/defect/123456789"
At least you will know if this is specific to java or not. Yes, it is strange that it fails on some machines and works on others, but the timing of those tests is not obvious from your post, and I wonder if this has anything to do with the underlying user credentials. (A user gets disabled for a period of time after a number of unsuccessful attempts). I am not positive that this is the issue you experience but I have seen when expired password caused the exact same error. API Keys are tied to a user, so when a user's password is expired, or when a user is inactivated (disabled) the same permissions(or the lack of them) is reflected in the key. For example, a user did not know that the password was expired because in the Rally UI they used SSO authentiation, but in the code they used either username/password or APIKey since the toolkit does not support SSO at this point. A 401 error would be more helpful, but instead a malformed JSON is generated.