Unable to instrument one of the Public Website through automatic tag injection. I found the below message in the developer's mode.
The key "" is not recognized and ignored.
[Deprecation] Setting cookies via `<meta http-equiv='Set-Cookie' ...>` no longer works, as of M65. Consider switching to `document.cookie = ...`, or to `Set-Cookie` HTTP headers instead. See https://www.chromestatus.com/feature/6170540112871424 for more details.
Blocked setting the `domain=XXXXXXXXXX.com.com; path=/; httponly;` cookie from a `<meta>` tag.
In the documentation, I found the following information.
RUM correlation requires that the
dtPC cookies be on web requests in order to link them to user actions. However, because
HTTPOnly flag. See cookies for complete details.
Is there any relevance between the error and the above information?
What is the solution in case they are relevant?
Hello @sebastian k.
I am getting the below message on all the pages/tabs even though web requests are available but no UEM.
<head id="Head1"><meta name="Generator" content="Generated by rb.indi @ 03-07-2019 12:24:18" /><meta charset="utf-8" /><meta name="viewport" content="width=device-width, initial-scale=1.0 " /><meta http-equiv="set-cookie" content="domain=XXXXX.com.com; path=/; httponly;" /><title>
Security - Online Banking Safety Features
"<meta http-equiv="set-cookie" content="domain=XXXXX.com.com; path=/; httponly;" />"
is not related to RUM, but this may be issue. I think that, script is doing something with cookies and in such case has problem? This may be case for support.
Hello @sebastian k.
The result of https://XXXXXXXX.com/system/js/rb_5e8dab8f?type=check is HTTP Error 404.0 - Not Found.
Any hint in this situation?
Thank you both of you for your responses.
As you can see the manual injected script is loading without any issue.
But when I test that the monitor signal passes through my infrastructure (as we are not receiving any UEM data) with the following method then I am getting HTTP Error 404.0 - Not Found and also Requested URL is automatically changing to the .aspx
Also, I can see the below message in the developer's mode for each request/page.
What should be the next step in this situation to make it work?
As I understand, webserver below this application is instrumented by oneagent? If yes I think you chould play with beacon url configuration in application settings, because such origin on js path may be blocked by webserver.
In general, this should be default path.
I had a similar problem, that when sending the callback (post) didn't go since the app server / security will not allow post, since the app itself didn't need it, obvisuly that was a 403 and not a 404, but to make it short, since this is a managed enviroment? do you have a cluster activegate?
What I did was change the beaconurl at the app settings, so it would not back to the app server, but to the cluster Activegate.
Obviusly there is some rule at the appserver that adds the aspx extension.
For me 404 means that web server is blocking your beacon. I've had such scenarios. Check on what path is your webserver receiving xhr's and try to modify beacon url to make it the same for agent.
I wanted to share the drop seen of this issue. There was a blunder from our side which is overlooked while installing the OneAgent.
The same server was instrumented by AppMon agent in the past and without uninstalling the AppMon Web Server Agent we installed the OneAgent on top of it which simply stopped the AppMon Web Agent Service but the Native Module information was still intact.
In short, after removal of AppMon and restarting the server beacon data started receiving as expected.