I want to reproduce a bug, these are the conditions :
GetStreamingEvents request should fail and preferably get 500 error from office365/exchange
The Resync request to send GetStreamingEvents periodically should keep failing.
Here is what I have tried so far :
I have tried to remove X-AnchorMailbox header and not send any Impersonation header but my syncing still works and GetStreamingEvents is a success.
On Exchange I moved users from one Database to another and Streaming events failed for a while till migration was in progress but it succeeded eventually.
Tried disabling Admin mailbox on exchange but that too didn't lead to any error.
Of course I tried to hardcode exchange's response but this hack is not 100% reliable.
I have Exchange2019 (acting as office365). I just want to lose my subscriptions somehow through Streaming notification mechanism of EWS. Please help me in this - what can I tweak on exchange or in my request to get streaming event failure.
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.
We do have a kendo scheduler bound to a remote data source.
The transport configuration of this scheduler's data source is done using remote urls (for CRUD), and this works perfectly,
On the server side, we make a lot of checks. So if some requirements are missing, Create, Update or event Destroy operations wouldn't pass and user will be shown the meaningful error.
The problem we're facing now is like the following :
For the Destroy action, what kind of response should we send back (from the server) to the scheduler component (in the browser on the client side ) to prevent removal of events in the UI?
We've tried :
Sending back HTTP 500 status code
Putting an error field in the response and linking it to the schema.error configuration
But events are still removed from the UI, nevertheless the error event is fired. We even use this event to notify errors to end used.
Thank you.
First the "email send" works fine but now It doesn't work anymore and when I print the error this is the text:
ERRORE {"name":"SparkPostError","errors":[{"message":"Message generation rejected","description":"Exceed Sending Limit (sandbox)","code":"1902"}],"statusCode":400}
Anyone can explein me how I'm wroing?
This error says that you have reached the limit of messages sent from sparkpostbox.com and now must register your own sending domain. You can read about how to do that here.
Each new SparkPost account may send a fixed number of messages addressed 'From:' sparkpostbox.com. After that, the idea is that you register your own sending domain and send from that instead.
The sandbox options allows you to send using the #sparkpostbox.com domain. It is currently limited to 50 sends for the lifetime of the account. At this time you should have a verified sending domain to use going forward. If you are looking for information on testing using SparkPost, take a look at this support document: https://support.sparkpost.com/customer/portal/articles/2361300
Source of the answer for your question is there: Error "Fatal SparkPostError: Exceed Sending Limit" when sandbox=true
For DELETE APIs, if we hit the API with invalid data, the API responds with proper error message. If we use the same HTTP connection object to hit another API, the request fails.
This issue is not seen for Create or Update APIs. Also if the Delete request is sent with valid data, then using the same HTTP connection object for next request works fine.
Please note that this behavior has implications for connection pooling in client applications, and we were just wondering if its known issue and if there is any available workaround.
I am trying to implement Google Check out (GCO) on a new server, the process seemed to work fine on the old server.
The error from GCO integration console is the timeout error you might expect if there is load on the server and/or the response takes longer than 3 seconds to respond.
To perform a test (not integrating with my database), I have set some code to send an email to me instead. If I hit the https url manually, I get the email and I can see an output to the screen. If I then leave it as that, Google still returns the Timeout error and I don't get an email. So I have doubts as to whether google is even able to hit the https url.
I did temporarily attempt to use the unsecure url for testing and indeed I received the email, however this solution isn't the route we've developed for, so the problem is something to do with the secure url specifically.
I have looked into the certificate which is a UTN-USERFirst-Hardware which is listed as accepted on http://checkout.google.com/support/sell/bin/answer.py?answer=57856 . I have also tried to temporarily disable the firewall with no joy. Does anyone have any sugestions?
Good to hear you figured out the problem.
I'm adding the links below to add a litle more context for future readers about how Google Checkout uses HTTP Basic Authentication:
http://code.google.com/apis/checkout/developer/Google_Checkout_XML_API.html#urls_for_posting
http://code.google.com/apis/checkout/developer/Google_Checkout_XML_API.html#https_auth_scheme
http://code.google.com/apis/checkout/developer/Google_Checkout_HTML_API_Notification_API.html#Receiving_and_Processing_Notifications