I am using Hot Chocolate to create a GraphQL server on my back end. I have several subscriptions which have been working reliably for months now, but they all of sudden don't work at all.
When I attempt to subscribe to a subscription using the Banana Cake Pop client, I receive this response:
{
"errors": [
{
"message": "The response type is not supported."
}
]
}
According to this answer to a similar question, this error message means that HTTP is being used rather than web sockets, which doesn't work because subscriptions are built on web sockets. So I clicked over to "Transport Details" tab, and sure enough it seems to be using HTTP.
I checked the settings, and the web socket endpoint does use websockets rather than HTTP: ws://localhost:5000/graphql.
I have not changed any settings, and I have never had this issue before. So, why does banana cake pop do this, and how can I make it use web sockets?
Related
I am hoping someone can point me in the right direction. I have a CF2021 Server which uses a Node.js websocket server and CF pages (via javascript) as a client. Messages from user to user work as expected, so no issue there.
This CF Server also has a custom API built using CFML that handles and routes inbound SMS messages. My question is; what would be the best way to send the SMS message (by now its json) to the Node.js websocket to it can send it to the user(s).
I tried using the same javascript that the browser client uses, but it appears that the CFML API script is "browser-less", so that doesn't work, or should it?
I thought something like Apache Groovy may be the solution, but I am having difficulties with any websocket example I have found.
Any suggestions would be greatly appreciated.
thanks in advance
Flow matters.
If you want to handle an incoming message by delivering it to all currently logged in users who are subscribed to messages of the current sort: set up your message handler to deliver using lucee/adobe-coldfusion websockets. Be forewarned, Lucee takes some setup time, but once running, it is a great solution.
If you don't need immediate delivery, or you need a super simple solution: I actually have had some success with "Long Polling" you just have to remember to use "flush" early in the request, before any pause/sleep, then loop your message lookup requests for new data, with a 1-5 second delay between each loop. Once new data is found, I like to return the request to the client, close that polling request and start a new polling request using the client side. I typically won't poll for more than 60 seconds. Even if the returned json object is empty.
I am making an app for shopify, that would allow costumers to send a message to a sites owner.
For this i have made a little server that would send the email on a post request.
Naturally, shopify would not let me do this. Instead, I am getting a cors, cross origin request issue. So I have created a private app, but they don't appear to provide me with the ability to make a post request to my server.
So I am looking into making a public unlisted app. But I am a bit burned out from my last attempt and am not in the mood to go off implementing oauth (for the first time) just to find out that I am still not getting the functionality that I need.
Can anyone please tell me what are the minimum requirements for me to be able to whitelist my server for ajax requests from the client side?.
My backend successfully validates the merchant and a session is returned, but when I complete the validation on the browser, it immediately cancels the transaction. There are a few similar complaints on the Apple Dev forum, but none seem to have been answered; I'm hoping you guys can help!
Out of all the event handlers on the ApplePaymentSession object, only onvalidatemerchant is called, then as soon as completeMerchantValidation with a valid session object (see payload below), oncancel is triggered.
Session config (on browser)
const session = new ApplePaySession(3, {
currencyCode: 'GBP',
countryCode: 'GB',
merchantCapabilities: [ 'supports3DS' ],
supportedNetworks: ['visa', 'masterCard', 'amex', 'discover' ],
total: {
type: 'final',
label: 'My Product',
amount: 9.99,
},
});
Request (on backend)
{
merchantIdentifier: 'merchant.MY.FQDN',
displayName: 'My Company Name',
initiative: 'web',
initiativeContext: 'MY.VERIFIED.FQDN',
}
Response (from Apple to backend, then sent to completeMerchantValidation
{
"epochTimestamp": 1552090296444,
"expiresAt": 1552093896444,
"merchantSessionIdentifier": "LONG_STRING",
"nonce": "XXXX",
"merchantIdentifier": "SAME_AS_IN_MY_MERCHANT_ID_CERT",
"domainName": "MY.VERIFIED.FQDN",
"signature": "XXXXXX-VERY-LONG-STRING-XXXXX"
}
I'm definitely sending this response into completeMerchantValidation as a JSON object and not a string, like so:
console.log('session is a', typeof(result), result); // says: object
session.completeMerchantValidation(result);
The domain name this is all happening from (and hosted on Firebase) is verified against this Merchant ID and I don't get any errors either in the backend or the browser console, no exception is thrown to catch, it just shows the Apple Pay tray, then says "Payment not complete" and hides the tray very quickly. Help!
UPDATE: Looking at the docs, it appears that startSession (which is being returned by onvalidatemerchant is being phased out, so I have tried replacing it with paymentSession (e.g. https://apple-pay-gateway-nc-pod5.apple.com/paymentservices/paymentSession); but I still get the same response and behaviour.
This solution may or may not work for you, but I was experiencing the same issue in that the session was being cancelled as soon as session.completeMerchantValidation() was called.
It boiled down to the merchantSession being created with a domainName value that was not verified (see: https://developer.apple.com/documentation/apple_pay_on_the_web/configuring_your_environment)
I used a local webserver broadcasting through Ngrok to validate a temporary URL by putting the apple-developer-merchantid-domain-association.txt file where it needed to be based on Apple Pay documentation.
After that, as long as I was using a sandbox iCloud account and a test Apple Pay card, passing the ngrok URL as the domainName value for the merchantSession request worked and Apple Pay finally started working locally. Note that I had to interact with my locally running web application through the ngrok url for Apple Pay to work.
I had the same issue where the payment sheet would display then go away without a chance to authorize the transaction. I made sure the domain was verified, the certificate was valid, and that I was actually receiving a response back from the server side request to Apple. Sorting through the process of elimination I came across certain interesting observations:
If the payment sheet disappeared immediately, it was usually due to a configuration issue with the server side request payload (for example, the "initiativeContext" was "something.com" when I was actually using "www.something.com" in the web browser address).
If the payment sheet disappeared after several seconds, it was usually due to a syntax issue or error in the client side JavaScript. In my case, I was not doing session.onpaymentmethodselected and session.completepaymentmethodselection correctly. So I removed all other Apple specific JS functions except for session.onvalidatemerchant and a subsequent call to session.completeMerchantValidation passing the Apple response from the server side request. It then worked.
If the Apple response from the server side request was in any way (even just the casing) changed from what Apple originally sent it would not work (for instance, "epochtimestamp":1668095263534," vs "epochTimestamp":1668095263534,").
Hope that helps.
I want to send SMS from AngularJS web application using Ozeki sms gateway. Can anyone tell me how to do this? pr suggest me some reference link or code sample.
Plain sending
Assume we skipping other protocols available inside Ozeki Sms NG product (like SMPP, Email, DB etc), and getting to HTTP protocol only, you can go this way:
Prerequisites:
Figure out best way for you to make HTTP request to send SMS
(I'm not AngJS guy so may be there are already few ways to make HTTP-request from Angular, but at least any Ajax method passing params to executing PHP-script for making HTTP request (with curl, file_get_contents) will be totally Ok).
Make sure your Ozeki SMS server is reacheable via IP/domainname etc by your PHP-script so your code can reach its endpoint.
Doing it:
Inside Ozeki install service provider like HTTP Client
http://www.ozekisms.com/index.php?owpn=195&info=service-provider-connections/http-client-connection
or HTTP Server (more powerful version of HTTP Client allowing call back URLs)
http://www.ozekisms.com/index.php?owpn=197&info=service-provider-connections/http-server-connection
Then according (to docs) execute request like
http://server_ip:9501/api?action=sendmessage&username=________&password=________&originatior=__________________&recipient=__________________&messagetype=SMS:TEXT&messagedata=______________
*Some fields are not necessary, it may vary depending on Ozeki version you use.
** port 9501 - is a default Ozeki HTTP port which may be changed in general settings, also it has HTTPS port as well. Basically the correct port is the same which you already use when accessing Ozeki Web GUI.
After executing sending request (try from browser or from something like Postman first) you should get responce in XML format informing you about result of your transaction.
Possible next step... DLRs
Getting delivery reports (if supported by your operator) is a common "i want it too" question.
In case you need them - there is great embedded feature inside "HTTP Server" connector (mentioned above).
Here you can see more details
http://www.ozekisms.com/index.php?owpn=431
"reporturl" - is a field you may use to set kind of "call back url". In other words in this optional field you may specify full URL and list fields to be passed along. So you only have to create your own endpoint to catch them (as GET request from Ozeki server) and use inside your software.
I'm starting with an address for an Exchange 2007 server:
user#domain.exchangeserver.org
And I attempted to send an autodiscover request, as documented at MSDN.
I attempted to use the generic autodiscover address documented at the TechNet White Paper.
So, using curl on PHP, I sent the following request:
<Autodiscover
xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
<Request>
<EMailAddress>user#domain.exchangeserver.org</EMailAddress>
<AcceptableResponseSchema>
http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a
</AcceptableResponseSchema>
</Request>
</Autodiscover>
to the following URL:
https://domain.exchangeserver.org/autodiscover/autodiscover.xml
But got no response, just an eventual timeout.
I also tried:
https://autodiscover.domain.exchangeserver.org/autodiscover/autodiscover.xml
With the same result.
Now, since my larger goal is to use Autodiscover with Exchange Web Services, and since all of the EWS URLs typically use the same sub-domain as the Outlook Web Access address, I thought I'd see if the same were true for autodiscovery URLS. Since the OWA URL is:
OWA: https://wmail.domain.exchangeserver.org
I tried:
https://wmail.domain.exchangeserver.org/autodiscover/autodiscover.xml
And sure enough, I got back the expected response.
However, I only knew the OWA sub-domain because it's the server I have access to and that I'm using to test everything. I would not know it for sure or be able to guess it if this were a live app and the user was entering in their own Exchange email.
I know that the autodiscover settings must be available without knowing the OWA URL, because I can enter:
user#domain.exchangeserver.org
into Apple Mail on Snow Leopard and it finds everything without trouble.
So the question is...
Should https://domain.exchangeserver.org/autodiscover/autodiscover.xml have worked, and I just missed a step when trying to connect to it? Or,
Is there some trick (maybe involving pinging the email address?) that Apple Mail and other clients use to resolve the address to the OWA subdomain before sending the autodiscover request?
Thanks to anyone who knows or can take a wild guess.
After a bit more banging my head against the Google, I found the following very helpful article on MSDN:
http://msdn.microsoft.com/en-us/library/ee332364.aspx
Specifically the section "Calling Autodiscover"
I'm still trying to figure out how to do a Active Directory Service Connection Point search via LDAP, but step 4, for my server at least, worked like a charm:
The application sends an unauthenticated GET request to http://autodiscover.contoso.com/autodiscover/autodiscover.xml. (Note that this is a non-SSL endpoint).
If the GET request returns a 302 redirect response, it gets the
redirection URL from the Location HTTP
header, and validates it as described
in the section “Validating a
Potentially Unsafe Redirection URL”
later in this article.
Sure enough, a request sent to:
http://domain.exchangeserver.org/autodiscover/autodiscover.xml
sent back a 302 redirect URL:
https://wmail.domain.exchangeserver.org/autodiscover/autodiscover.xml
But this article gives a series of steps, so anyone wanting to implement autodiscover for an Exchange client has 5 things to try before giving up.