I was stuck for a day The bot isn't response back my command /start after setup web hook.
I swear it working fine on local with polling method. But not working after setup web hook . I'm using flask + heroku
This is my full code:
https://pastebin.com/zBesJBjb
Info : Window 10 Pro x64,
Python 3.8,
PythonTelegram Bot = 13.4.1
My WebhookInfo response:
{
"ok": true,
"result": {
"url": "https://hello-world.herokuapp.com/xxxx",
"has_custom_certificate": false,
"pending_update_count": 0,
"max_connections": 40,
"ip_address": "54.165.0.49"
}
}
My log after deploy to heroku:
https://pastebin.com/sFD403LU
IISC, you don't process the incoming updates anywhere in webhook_handler. You'll have to either call dispatcher.process_update(update) or put the update in the dispatchers update_queue if you use dispatcher.start() in order to have the update processed. Also two more notes:
telegram.Update.de_json(request.get_json(force=True), updater) should be changed to telegram.Update.de_json(request.get_json(force=True), updater.bot)
if you don't use the updater for fetching updates, you don't need it at all, you just need a Dispatcher
I recommend to have a look at PTBs wiki page about webhooks. There even is a dedicated section on Heroku. Admittedly, it uses updater.start_webhook, but I didn't really see anything in your code that explains why you're using flask instead of the built-in solution.
Related
I am trying to use MikroORM repositories, but I keep getting the Global Context validation error when I use them while debugging in Visual Studio Code. I am using the RequestContext middleware, just as the documentation and demo applications suggest. The error does not occur when I run the application in a terminal window instead of by debugging.
I am currently running Visual Studio Code version 1.68.1 on Windows 10, using Node version 18.2.0.
Error Recreation:
Install the sample application Express + MongoDB + JavaScript from the Mikro-orm Example integrations (https://github.com/mikro-orm/express-js-example-app).
Follow the instructions in the README.md to run the application.
Use Postman (or equivalent) to create an author.
3.1. POST http://localhost:3000/author\
3.2. Body (raw/JSON):
{
"name": "test person",
"email": "test#test.com",
"age": 42
}
Use Postman (or equivalent) to retrieve authors.
4.1. GET http://localhost:3000/author
Copy the id of the author you just created.
Use Postman (or equivalent) to update the author.
6.1. PUT http://localhost:3000/author/<id from step 5.>
6.2. Body (raw/JSON):
{
"name": "test 'success' person"
}
NOTE: This will succeed, proving that everything is configured correctly. I have tried this with both the repository's version of Mikro-orm as well as the current latest version (5.2.3).
Stop the application (Ctrl-C in terminal)
Attach the debugger
8.1. Open the file app\server.js
8.2. Open VS Code's Run and Debug panel.
8.3. Click the "Run and Debug" button.
Use Postman (or equivalent) to update the author.
9.1. PUT http://localhost:3000/author/<id from step 5.>
9.2. Body (raw/JSON):
{
"name": "test 'failure' person"
}
This time the update will fail with the message:
"Using global EntityManager instance methods for context specific
actions is disallowed. If you need to work with the global instance's
identity map, use allowGlobalContext configuration option or
fork() instead."
Within the sample application, the error occurs in author.controller.js, within the router.put('/:id', async (req, res) section, specifically on the line await DI.authorRepository.flush() (line 55). However, experimentation suggests that the error will occur the second time you make any repository call. For example, if you duplicate the findOneOrFail line like this:
const author = await DI.authorRepository.findOneOrFail(req.params.id);
const foo = await DI.authorRepository.findOneOrFail(req.params.id);
the error will occur on the second call to .findOneOrFail.
The error is being thrown in #mikro-orm/core/EntityManager.js, in the getContext method (line 737). When the second call to the repository occurs, getContext is called multiple times. The first time has the following call stack
EntityRepository.flush
MongoEntityRepository.em (get)
EntityManager.getContext
This call is successful.
However, the second call to getContext fails. It has this call stack:
EntityRepository.flush
EntityManager.flush
EntityManager.getUnitOfWork
EntityManager.getContext
The issue seems to be that between the two calls to getContext, em._id goes from not 1 to 1. It looks to me like the EntityManager with an _id of 1 is the global context we shouldn't be using. However, when you run the code without debugging, em._id is not 1 during any of these calls.
I have not been able to figure out why the context is not retrieving the correct entity manager when in debugging mode.
I need to be able to launch my Electron app from the the browser (like sign in to Slack does). I know that I can add my protocol name to my Electron app using app.setAsDefaultProtocolClient(protocol[, path, args]) in Electron.
Then in electron-builder, I can use the package.json config build.mac with the extendInfo property to define "The extra entries for Info.plist". This however is the only instructions the docs give on how to use it.
What is the correct way add a protocol to the macOS info.plist using electron and electron-builder config build.mac.extendInfo and be able to use it as described?
(Posted a solution on behalf of the question author to move it to the answer space).
It now works with the following - I have added this to my Electron package.json:
"protocols": {
"name": "my-app",
"schemes": [
"my-app"
]
},
"mac": {
"target": "dmg",
"extendInfo": "my-app"
},
I have this in the electron.js:
app.setAsDefaultProtocolClient('my-app');
And this in my React browser client app code to launch the application from the browser:
document.location = 'my-app://open?url='
This question relates to how custom schemes are used to receive OAuth responses, as in my code sample which you can run locally, then use deep linking etc:
Code
Blog Post
Points of interest:
An interstitial web page returns control to the browser app - see this page
My package.json exposes the scheme for Electron deployment
This should give you something to compare against. Here is the key code:
INTERSTITIAL WEB PAGE INVOKING APP
window.addEventListener('DOMContentLoaded', function() {
var redirectUri = 'x-mycompany-desktopapp:/callback';
if (window.location.search) {
redirectUri += window.location.search;
}
document.getElementById('continueButton').onclick = function() {
window.location.href = redirectUri;
};
}
REGISTERING THE SCHEME
This gets picked up by Electron packager and included in platform specific binaries, resulting in OS specific registration:
"build": {
"protocols": {
"name": "finaldesktopapp",
"schemes": [
"x-mycompany-desktopapp"
]
}
},
RECEIVING NOTIFICATIONS
This enables the following code to work in the main side of the app, as specified in the main.ts file:
app.setAsDefaultProtocolClient(this._configuration.oauth.privateSchemeName);
Finally you register a callback that can parse the URL and take whatever is the appropriate action - completing a login in my case.
private _receiveNotificationInRunningInstance(privateSchemeUrl: string) {
}
The mechanics are a little tricky and the notification is received differently on macOS to Windows / Linux. See this source file and its comments which explain the details.
Past two days, I have been trying to configure MS Teams connector following this tutorial:
https://learn.microsoft.com/en-us/learn/modules/msteams-webhooks-connectors/7-exercise-o365-connectors
I configured the connector via Connectors Developer Dashboard.
Then I tried both, cloning and reconfiguring this sample:
https://github.com/OfficeDev/TrainingContent/tree/master/Teams/60%20Webhooks%20O365%20Connectors/Demos/03-o365-connector
and also bootstrapping the project via yo teams, following the tutorial step-by-step.
After building the project and serving it via ngrok, I can sideload the connector into Teams (tried both, desktop app and web), it successfully brings me to configuration page, but never allows me to save the connector settings. I always get this error:
Unable to save “My First Teams Connector” connector configuration. Please try again.
I adapted the code and debugged it to see, that the call to /api/connector/connect succeeds and saveEvent.notifySuccess() is called.
Then I noticed, that right after saving the connector via browser, this error appears in the console:
{
"seq": 1597590187271,
"timestamp": 1597593891957,
"flightSettings": {
"Name": "ConnectorFrontEndSettings",
"AriaSDKToken": "d127f72a3abd41c9b9dd94faca947689-d58285e6-3a68-4cab-a458-37b9d9761d35-7033",
"SPAEnabled": true,
"ClassificationFilterEnabled": true,
"ClientRoutingEnabled": true,
"EnableYammerGroupOption": true,
"EnableFadeMessage": false,
"EnableDomainBasedOwaConnectorList": false,
"EnableDomainBasedTeamsConnectorList": false,
"DevPortalSPAEnabled": true,
"ShowHomeNavigationButtonOnConfigurationPage": false,
"DisableConnectToO365InlineDeleteFeedbackPage": true
},
"status": 500,
"clientType": "SkypeSpaces",
"connectorType": "f39fe17c-6452-4879-b692-a93d73684348",
"name": "handleMessageError"
}
Any idea what could be incorrectly configured, or whether there is a place to check for more descriptive error? Log of desktop Teams was not helpful either.
ConnectorID: f39fe17c-6452-4879-b692-a93d73684348
So, what really helped me in the end for that particular tutorial:
run gulp ngrok-serve
configure the connector following the tutorial (with valid domains; excluding protocol) on Connectors Developer Dashboard
extract the content of packaged connector
adapt extracted manifest.json with newly created connector ID (both occurrences)
repackage the connector as zip
upload to Teams & configure it
I filled the valid domains field with xxxxxxxx.ngrok.io which is the domain of my configuration page.
Be careful, if you update an existing connector, apparently these changes needs time to be taken into account. To be sure, you can create a fresh new connector.
I'm doing a tiny offline-able web app / PWA. It's meant to be opened from a home screen icon and mimic a regular app by loading entirely from a cache when offline.
The app is written using Vue and to accomplish the above I'm just using their PWA template and whatever it generates. To the best of my knowledge what this does is set up workbox using the GenerateSW plugin to precache everything in the Webpack build, and registers it using register-service-worker. That is, I have fairly little control out of the box over the fine details, it's meant to be a turnkey solution.
That said, I'm not sure how to actually load a new build of the application when it's available. The above can detect this - the generated SW registration file with my changes looks like this:
import debug from 'debug';
import { register } from 'register-service-worker';
if (process.env.NODE_ENV === 'production') {
register(`${process.env.BASE_URL}service-worker.js`, {
ready(...args) {
log('App is being served from cache by a service worker.\n', ...args);
},
cached(...args) {
log('Content has been cached for offline use.', ...args);
},
updated(...args) {
log('New content is available; please refresh.', ...args);
},
offline(...args) {
log('No internet connection found. App is running in offline mode.', ...args);
},
error(error, ...args) {
log('Error during service worker registration:', error, ...args);
}
});
}
When I make a new build of the application, and I refresh the app in a browser, the updated() callback is executed, but nothing else is done. When I tried adding:
window.location.reload(true);
which should be a forced refresh, I just get a refresh loop. I'm assuming this is because the service worker cache is completely independent from the browser cache and unaffected by things like the above or Ctrl+F5. (Which makes the "please refresh" rather misleading.)
Since this is going to mimic a native app, and it's supposed to be a simple line-of-business tool, I don't really need to do anything more complicated than immediately reload to the new version of the app when an update is available. How can I achieve this?
Okay so the behaviour I've observed is that the update does happen automatically, it's just not obvious as to what the exact sequence of events is. I'll try to describe my best understanding of how the generated service worker works in the installed PWA scenario. I'll speak in terms of "app versions" for simplicity, because the mental model behind this is closer to how apps, not webpages work:
You deploy v1 of your application to a server, install / precache it on a device, and run it for the first time.
When you suspend and resume your app, it does not hit your servers at all.
The app will check for an update when it's either cold-started, or you reload the page, i.e. using the pull down gesture on Android.
(Possibly also periodically as the cached version goes stale, but I haven't checked this.)
Say you've deployed v2 of your app in the meantime. Reloading an instance of v1 of the app will find this update, and precache it.
(One reason why prompting the user to reload doesn't seem to make sense. Whatever the reloading is meant to accomplish has already happened.)
Reloading an instance of v1 again does absolutely nothing. The app remains running between reloads, and you'll just get v1 afterwards.
(Reason number two why prompting the user to reload is pointless - it's not what causes a new version of an app to load.)
However, next time you cold start your app - e.g. nuke it from the task switcher and reopen - v2 of your app will be loaded and I'm guessing v1 will get cleaned out. That is, your app must fully shut down so an update will load.
In short, for an application to be updated from v1 to v2, the following steps need to occur:
Deploy v2 to server
Refresh instance of v1 on device, or shut down and reopen the app.
Shut down and reopen the app (again).
I can't seem to find anything official about this: Does Parse.Config work on Parse Server? It used to work on Parse.com but when I try to migrate to Parse.Server, when trying the REST API it seem to fail:
GET http://localhost:1337/parse/config
Passing in my app ID. I read somewhere Config does not work on Parse Server, but wanted to confirm
Although is not officially supported as mentioned on the docs,there is a way to make it work. It is still an experimental implementation though.
As mentioned here & here, you should set the environment variable:
PARSE_EXPERIMENTAL_CONFIG_ENABLED=1
Then restart your node server. In case you deployed it on heroku for example you should on cli heroku restart -a <APP_NAME>
If that doesn't work I would suggest to simply add your route with your configuration options on your project's index.js file where express is initialized like so.
var parseConfig = {
"params": { /*...put your options here*/ }
};
// :one? is for old SDK compatibility while is optional parameter.
app.all('/parse/:one?/config', function (req, res) {
res.json(parseConfig);
});