I'm using the JavaScript version of the botframework. I've followed the documentation to enable telemetry logging in Application Insights. When I access the logs I can see that custom events are being logged.
The issue is that the bot specific identifiers, such as user_Id, session_Id and conversation_Id are not being logged. This can be seen in the screen capture below
In the applicationInsightsTelemetryClient.js file there is a function called addBotIdentifiers. As far as I can tell, it is this function that is responsible for adding the bot specific identifiers.
The first lines of the function look like this:
function addBotIdentifiers(envelope, context) {
if (context.correlationContext && context.correlationContext.activity) {
Inspecting this function shows that the context argument is always null.
This leads me to my questions.
Why is it null?
Any suggestions on what I need to do to have it set appropriately?
Update
In digging into this further it appears the code starting at line 26 in the applicationInsightsTelemetryClient.js file isn't being called. Could this be the cause of the missing context later on in the addBotIdentifiers function?
Looks like the documentation has a missing line in step 7. We will correct the document ASAP. Meanwhile, please add the below in your index.js following https://github.com/microsoft/BotBuilder-Samples/blob/main/samples/javascript_nodejs/21.corebot-app-insights/index.js#L113
// Enable the Application Insights middleware, which helps correlate all activity
// based on the incoming request.
server.use(restify.plugins.bodyParser());
Further investigation has shown what the issue was. It's not immediately obvious.
I compared the code in my index.js file with the one in the 21.corebot-app-insights BotBuilder sample.
Note that the setup of the Restify server happens after the creation of the adapter bot adapter. It is also after the configuration of the main dialog and the middleware.
In my code the setup of the Restify server and the bot adatper / dialogs was intermingled. This appears to have been the cause of the problem.
The main lesson here for me, and for anyone who stumbles across this post later, is that the setup of the Restify server should be at the end of the index.js file. To ensure all of the bot framework is setup first.
Related
I've got a new API from the backend team in a new project, when I call the api it returns "you need to enable java...", whereas I had used Postman for another project before... is it related to api, server or something else?
I don't think that POSTMAN is capable of executing JavaScript in its console.
Try doing the same in the web browser it will work (You won't see this error message).
I spent some times pondering on this trepidation.. and then suddenly i realized what was going on..
the endpoint does not exist, it could be a misspelling
not in the same directory as you expect it to be,
try adding or removing "/" at the beginning of the url, particularly if you don't specify the hostname, i.e. fetch('getusername') is different from fetch('/getusername') .
. This acceptable in development but NOT when already deployed, it points to different path.
the endpoint may be working fine in the Development,
but somewhere within in the Production/Staging, it generated some exception.
I updated Postman and now it works. I'm not sure if it was because of the update or the restart.
I had this problem with a project built using the new template in Visual Studio 2022 for a React app with .NET Core.
In my case I was only getting the response "You need to enable JavaScript to run this app" with calls to a new controller I added. Calls to the built-in WeatherForecastController were working just fine. My new controller was configured the same as the built-in controller so I could not figure out why this was happening. It has to do with how this project template creates both a React app and a back-end API both accessible on the same port. There's a setupProxy.js file that defines routes that should be forwarded to the API. All other routes are redirected to index.html. This is actually what was happening in my case, because my new controller had not been added to setupProxy.js the middleware was redirecting the request to index.html, and because it came from Postman rather than a browser the message regarding enabling JavaScript is displayed.
The solution is that each controller must be explicitly mapped in setupProxy.js or else it won't be proxied correctly. After making this change it worked perfectly in Postman as well as fetch calls from the React app.
const context = [
"/weatherforecast", // built-in controller than comes with the project template in VS2022
"/recaptcha" // controller I created (this line must be added)
];
While calling the REST API with the postman, if you miss the end-point, then also this issue will come, add the end-point to the URL and check
What worked for me was to turn-off / deselect the user-agent header field under request
I'm trying to write a firebase function to send a transactional e-mail with SendGrid whenever it gets triggered by a HTTP request, but at the moment I'm having real difficulty getting the function to be able to access the configuration variables that I've set with the sendgrid key which is obviously a real problem...
I've set the config variable with the below command:
$ firebase functions:config:set sendgrid.key="KEY_HERE"
When I run firebase functions:config:get to list all the config values, it returns the correct value in the terminal:
{
"sendgrid": {
"key": "KEY_HERE"
}
}
But when I try to access it from my function (tried with both TypeScript & Vanilla JS setups), functions.config() just returns an empty object.
Has anyone encountered & solved this issue before, or am I doing something wrong? In either case, if anyone could give me a pointer then that'd be much appreciated!
Edit the first
I have deployed the function, and called it while hosted and looking at the logs, you can see the correct values. However, I still see the problem when I call the function when served locally on my machine for testing, which is a problem as I'd like to not have to deploy a function just to see if it works...
I'm loading stripe into my payment page like so:
<script src="https://js.stripe.com/v3/"></script>
This works perfectly in my local test environment but in production, the following console error appears:
Uncaught Error: It looks like Stripe.js was not loaded correctly
at new e (controller-84824401a25a5595fc578f767b4d5c27.js:1)
at controller-84824401a25a5595fc578f767b4d5c27.js:1
at Object.bnjt (controller-84824401a25a5595fc578f767b4d5c27.js:1)
at t (shared-d3604a85e14ef273096e09821a0e4c2a.js:1)
at Object.3 (controller-84824401a25a5595fc578f767b4d5c27.js:1)
at t (shared-d3604a85e14ef273096e09821a0e4c2a.js:1)
at window.webpackJsonp (shared-d3604a85e14ef273096e09821a0e4c2a.js:1)
at controller-84824401a25a5595fc578f767b4d5c27.js:1
I can't work out what might be causing the error. I'm using HTTPS in production and can see the JS file source downloading successfully. Any tips?
Solved following advice from #NathanCasebolt. SO mods deleted his original answer:
“For me, the resolution to this error was as simple as spell-checking
my variables. In my backend server code, one of my variables was
wrongly capitalized. Since the misspelled variable was part of the
function that retrieves my publishable key, the key returned from the
server as null. This, in turn, disrupted creation of the Stripe object
and threw this error. If I were you, I'd check to make sure (1) that
the publishable key on your frontend matches the publishable key in
your dashboard, and (2) that you're not doing anything that might
disrupt serving this key to Stripe.”
The StackOverflow mods felt this didn’t answer the question and
required too much clarification. So, to clarify, the problem for me
was this line:
var stripe = Stripe(‘{PUBLISHABLE_KEY}’);
I set things up to retrieve my publishable keys from my server, to
give me more flexibility in switching between test keys and live keys.
Since my one of my server variables was wrong, I was providing Stripe
with a bad key (no key, really), and that’s what threw the error. This
is why I suggest you check the publishable key you’re using to create
the Stripe object, to make sure that the one you’re using to create
the object is there, and that it matches the publishable key you have
on your Stripe dashboard."
In my case, this is exactly what I'd done wrong: provided an empty publishable key when initialising Stripe. Ultimately a very simple mistake compounded Stripe's obtuse error message.
I am using winston logging framework and logging on basis of log level, but now i am facing difficulties in tracking down bugs. So we decided to make logging on per user basis, and this is where i ran into problem.
What i want to acheive?
log file for every user will be generated on every hour. (We can skip every hour constraint in this thread) and every user has unique identifier 'uid'.
What i have?
I have followed architecture as used here 'https://github.com/agendor/sample-hapi-rest-api'. Some additional lib modules exist too.
Currently i am using winston library (but i can afford to replace this if needed).
Brief introduction of flow
Currently, i have access to request object in handler function only, but i want to log events in DAO, library functions too ( on per user basis). 'Uid' is available to me in handler function in request object as i put uid in request in authentication middleware.
My solution (which is not elegant)
pass request object ( or only uid) to every function and log (using winston) event. Custom transport will determine where (in which file, on basis of uid) to put the log.
Certainly, this is not elegant way as every function must have uid parameter in order to log event, which seems bad.
What i want from you?
A better, elegant approach which is scalable too.
Related post: https://github.com/hapijs/discuss/issues/51
Try taking a look at Continuation-Local Storage:
https://github.com/othiym23/node-continuation-local-storage
Heres a good article on implementing it within express:
https://datahero.com/blog/2014/05/22/node-js-preserving-data-across-async-callbacks/
I've seen a few people having problems with the oAuth1.0 using hello.js with Twitter, LinkedIn etc. Unfortunately, I am one of them. Trying everything I can to fix it, but I need help.
To explain:
I have my Twitter credentials initialised:
hello.init({
'twitter' : '*******************'
},
{
redirect_uri:'****************',
oauth_proxy: 'https://auth-server.herokuapp.com/proxy'
});
(I presume that the 'oauth_proxy' in my case here is correct?)
Apart from that, I have tried calling the function in the button tag like so:
onclick="hello.login('twitter');">
I have seen people making errors having skipped the 'https://auth-server.herokuapp.com/#signin' step but I have all my credentials inputted there for the mean time. But, one question:
The 'Reference' section, is that just a nickname kind of thing? And what's the 'Domain' section about?
The error that I'm receiving is a 401 error message.
Another question:
Do I need all of the 'twitter.js' & 'client_id.js', or is including 'hello.js' sufficient?
I appreciate any effort to help me with this. Thank you.
As Andrew said (after all, he is the one who wrote hello.js), one of the problems could be related to the callback URL. I found out after a while that Twitter (unlike Facebook) does not accept 'localhost', so instead one has to write 127.0.0.1.
That solved all my problem when being stuck at the same point.
So yes, the reference is a nickname e.g. "dropbox", and the domain field is the domains e.g. "myapp.com". Its advised to fill both these in for your own reference and their misconfiguration wont lead to a 401.
The 401 is likely that your client id / secret is incorrect. Or the redirect_uri defined in hello.init does not match the Callback URL you assigned to that client id when you registered with a third party service.
The error handler hello(network).login().then(successHandler, errorHandler) should give more information. Can you attach that too your question?
"client_id.js" is a demo script which defines the credentials used for my hellojs demos. Do not include it!
However you may like this approach for maintaining your application credentials in a separate file - this approach is left up to you.
All you need to include to get started is dist/hello.all.js this contains hello js and all the third party configurations listed.