I need to automate this following website:
https://ekrs.ms.gov.pl/web/wyszukiwarka-krs/strona-glowna/index.html
When I work on my automation in my testing environment then all is fine, but in test I use "visible" normal mode.
But on enduser PC this should be run in headless mode, so I checked my code and I notice that with headless mode this website returns: The requested URL was rejected. Please consult with your administrator
Any concept why this issue occurs and how to solve this problem?
Thank you in advance
I also have this following information get back from WebDriver:
Starting ChromeDriver 96.0.4664.45
(76e4c1bb2ab4671b8beba3444e61c0f17584b2fc-refs/branch-heads/4664#{#947})
on port 9515 Only local connections are allowed. Please see
https://chromedriver.chromium.org/security-considerations for
suggestions on keeping ChromeDriver safe. ChromeDriver was started
successfully.
DevTools listening on
ws://127.0.0.1:63205/devtools/browser/ffacc4cb-af7c-4157-881d-a8c7db522d30
[1206/145642.826:ERROR:command_buffer_proxy_impl.cc(125)]
ContextResult::kTransientFailure: Failed to send
GpuControl.CreateCommandBuffer. [1206/145645.262:INFO:CONSOLE(402)]
"The AudioContext was not allowed to start. It must be resumed (or
created) after a user gesture on the page.
https://...........goo.gl/7K7WLu", source:
https://ekrs.ms.gov.pl/TSPD/08c5699bd4ab2000035ad69152344c2a5571187707e8019758fff5530615875b3778567088bde213?type=11
(402) [1206/145645.263:INFO:CONSOLE(402)] "The ScriptProcessorNode is
deprecated. Use AudioWorkletNode instead.
(https://.........bit.ly/audio-worklet)", source:
https://ekrs.ms.gov.pl/TSPD/08c5699bd4ab2000035ad69152344c2a5571187707e8019758fff5530615875b3778567088bde213?type=11
(402) [1206/145645.264:INFO:CONSOLE(405)] "The AudioContext was not
allowed to start. It must be resumed (or created) after a user gesture
on the page. https://...........goo.gl/7K7WLu", source:
https://ekrs.ms.gov.pl/TSPD/08c5699bd4ab2000035ad69152344c2a5571187707e8019758fff5530615875b3778567088bde213?type=11
(405) [1206/145645.265:INFO:CONSOLE(408)] "The AudioContext was not
allowed to start. It must be resumed (or created) after a user gesture
on the page. https://...........goo.gl/7K7WLu", source:
https://ekrs.ms.gov.pl/TSPD/08c5699bd4ab2000035ad69152344c2a5571187707e8019758fff5530615875b3778567088bde213?type=11
(408) [1206/145645.265:ERROR:web_contents_delegate.cc(228)]
WebContentsDelegate::CheckMediaAccessPermission: Not supported.
[1206/145645.265:ERROR:web_contents_delegate.cc(228)]
WebContentsDelegate::CheckMediaAccessPermission: Not supported.
[1206/145645.306:ERROR:gl_utils.cc(318)] [.WebGL-0000249C00081B00]GL
Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU
stall due to ReadPixels [1206/145645.467:ERROR:gl_utils.cc(318)]
[.WebGL-0000249C00081B00]GL Driver Message (OpenGL, Performance,
GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels
[1206/145645.564:ERROR:gl_utils.cc(318)] [.WebGL-0000249C00081B00]GL
Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU
stall due to ReadPixels [1206/145645.652:INFO:CONSOLE(0)]
"[.WebGL-0000249C00081B00]GL Driver Message (OpenGL, Performance,
GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels", source:
https://ekrs.ms.gov.pl/TSPD/?type=20 (0)
[1206/145645.652:INFO:CONSOLE(0)] "[.WebGL-0000249C00081B00]GL Driver
Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due
to ReadPixels", source: https://ekrs.ms.gov.pl/TSPD/?type=20 (0)
[1206/145645.654:INFO:CONSOLE(0)] "[.WebGL-0000249C00081B00]GL Driver
Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due
to ReadPixels", source: https://ekrs.ms.gov.pl/TSPD/?type=20 (0)
EDIT: 2021/12/08
Finally I find out that a had to add capability user-agent as Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.93 Safari/537.36. The interesting thing was that when I was used 60.0.3112.50 instead 96.0.4664.93 then my automation works well in Headless when it come to navigate to the desired wegsite, but stoped to work on even in Normal mode when it comes to using this website - I mean navigation to website works but after filling the form and submiting data I started to get the same issue ....consult administrator.......
To clarify the matter:
Before I added args user-agent in normal mode works both navigate and search feature.
Before I added args user-agent with outdated 60.0.3112.50 setting, in normal mode works navigate but search stop working.
So now my question changes to:
Why, with out-of-date settings in user-agent , the navigation to the page work properly, but the search on this page does not work? Could it just be related to the strange configuration, design of this site?
options.add_argument("disable-blink-features")
options.add_argument("disable-blink-features=AutomationControlled")
only these two lines are solution
and now it work perfect
Related
Im hoping someone could help me please. I am trying to retrieve time and date from the Sim800L and I am coming short. I have a Sim800L here and I am communicating with it successfully over the Arduino IDE. I have used the following AT commands as suggested online with the following results.
AT+CCLK?
+CCLK: "04/01/01,03:59:51+00"
OK
AT+CLTS=1
OK
AT&W
OK
AT+CLTS?
+CLTS: 1
OK
After restarting, the date and time however is not set to network time. The network is a national carrier and should be able to do this.
AT+CCLK?
+CCLK: "04/01/01,03:59:51+00"
OK
Any ideas?
Thank you
I found the same trouble. in this page embedded world i Found something that works for me. it is add the following instruction
AT&W
Read current time (You can see that the time is not right):
AT+CCLK?
+CCLK: "04/01/01,00:14:12+22"
OK
Enable auto network time sync :
AT+CLTS=1
OK
Check if value is set :
AT+CLTS?
+CLTS: 1
OK
Save the setting to permanent memory so that module enables sync on restart also :
AT&W
OK
Restart the module and check time :
AT+CCLK?
+CCLK: "18/06/21,12:00:21+22"
OK
and it is all.
You do correct but
Base on "SIM800 Series_AT Command Manual_V1.09" Edited on 2015-08-03
in page 154 in "6.2.12 AT+CLTS Get Local Timestamp" section
"Support for this Command will be network dependent."
Change your network provider
In the UK, "AT+CCLK?" usually works (the network sets this time) IF using a network-branded-SIM (eg. EE or O2 branded). However for SOME MVNO-SIMs (Mobile Virtual Network Operators SIMS) "AT+CCLK?" does NOT work (even where the same network-branded-SIM does).
Under these cases (for my SIM800L), if you need a valid time (for example so you can send a GPRS-email with a valid time-stamp), you have to manually set the time using: AT+CCLK="21/10/15,18:55:00+04"
Bug:
I'm consistently getting error code -1009 "The Internet connection appears to be offline." errors when making URLSession requests in an Apple Watch extension on an Apple Watch Series 3 when connected to the Internet only via LTE.
Steps to Reproduce:
Install the app.
Configure your device so that it's only on LTE.
Verify your connection to LTE using iMessages, e.g.
Launch the app.
Initialize a URLSession using the .default or .ephemeral session configuration.
Make a data task request for any known-good https URL.
Expected Behavior:
The request manages to reach the destination.
Observed Behavior:
The request fails immediately with error code -1009 "The Internet connection appears to be offline."
Code Sample:
let config = URLSessionConfiguration.ephemeral
let sesh = URLSession(configuration: config)
let url = URL(string: "https://google.com")!
sesh.dataTask(with: request) { (_, _, error) in
print(error)
}.resume()
NOPE: SEE UPDATE #3 BELOW: The crucial missing element: you must set the waitsForConnectivity flag on your session configuration to true.
let config = URLSessionConfiguration.ephemeral
config.waitsForConnectivity = true
let sesh = URLSession(configuration: config)
let url = URL(string: "https://google.com")!
sesh.dataTask(with: request) { (_, _, error) in
print(error)
}.resume()
If you do not set that flag, the requests fail immediately because LTE access isn't available instantly but only after the briefest of delays. Setting this flag to true makes the requests work. In my testing there even seems to be no appreciable difference in timing between enabling the waitsForConnectivity over LTE and making the same request without enabling waitsForConnectivity but conducted over WiFi, almost like the waiting period enabled by waitsForConnectivity in some scenarios is a next-turn-of-the-runloop kind of situation.
Update #1
I am unable to make any requests over LTE. When waitsForConnectivity is set to true, the requests just timeout according to the timeout properties of the session config. When waitsForConnectivity is false, the requests fail immediately. I'll update my question and answer when I have more information. I'm waiting on a response from an Apple TSI request which usually takes several days.
Update #2
Adding to the mystery, the same sample code runs fine over cellular on two other developers' hardware. I know that my hardware is good because Apple's apps fun fine over LTE on it (phone calls rolling down the highway with nothing but my watch in the car). So there's something really fishy going on. I've asked Apple DTS to look into this, and they can't reproduce the issue either. I'll be following up with them as soon as I can.
Update #3
Sometime in the intervening weeks after I last updated this post, cellular requests started working in my apps. I didn't change anything about my watch, no software updates, no resets, nothing. I didn't even recompile the code; the same build is still on my watch as previously. It just started working as expected, same as it did on other developers' devices.
The only thing strange I noticed is that I got three, back-to-back, identical SMS messages from AT&T notifying me that my Apple Watch is now linked to my iPhone number. Which is strange, because that linkage supposedly occurred the night I unboxed my phone, not two months later. I have no idea if this is related to my issue. All I know is that cellular requests are now working.
I had the same problem but was developing an App for the iPhone. This is what finally solved the problem. I set the configuration objects property:
config.allowsCellularAccess = true
This is very confusing, because the Apple documentation states that this property is set to true by default... but in my case it was not. Also, even though I am using "background tasks," and they are always meant to wait for connectivity, I also set waitsForConnectivity = true, too, just in case.
Just in case someone runs into this error but has everything set up correctly. I was running my project from xCode onto a real device but couldn't get past the internet connectivity issue.
In the code there was a check for __DEV__ to determine what API url to use.
I was building this for running not testing so i assumed it would make __DEV__ false. but it did not, so I had to change the code for that check and set it to a non-localized api url.
even if you are injecting your url, it might not grab the correct one based on if it thinks it is a DEV build or not.
I'm trying to get basic Bluetooth LE connections working in my app, but I'm running into problems. I have a couple of sensors that I can connect to just fine with the iOS version of this app, but I simply cannot connect to them with the Android version. The only thing I seem to be able to connect to is a beacon I've set to configuration mode.
After checking my ADB logs again, I noticed that whenever it fails to connect to a device, there's always four calls to bt_osi_alarm and bta_gattc_conn_cback. I'm wondering how to interpret this.
An unsuccessful connection attempt:
D/BluetoothGatt(17824): connect() - device: 00:17:E9:C0:86:14, auto: false
E/bt_osi_alarm(14357): reschedule_root_alarm alarm expiration too close for posix timers, switching to guns
...
E/bt_osi_alarm(14357): reschedule_root_alarm alarm expiration too close for posix timers, switching to guns
E/bt_osi_alarm(14357): reschedule_root_alarm alarm expiration too close for posix timers, switching to guns
E/bt_osi_alarm(14357): reschedule_root_alarm alarm expiration too close for posix timers, switching to guns
...
W/bt_btif (14357): bta_gattc_conn_cback() - cif=3 connected=0 conn_id=3 reason=0x0002
W/bt_btif (14357): bta_gattc_conn_cback() - cif=4 connected=0 conn_id=4 reason=0x0002
W/bt_btif (14357): bta_gattc_conn_cback() - cif=5 connected=0 conn_id=5 reason=0x0002
W/bt_btif (14357): bta_gattc_conn_cback() - cif=6 connected=0 conn_id=6 reason=0x0002
D/BtGatt.GattService(14357): onConnected() - clientIf=6, connId=0, address=00:17:E9:C0:86:14
D/BluetoothGatt(17824): onClientConnectionState() - status=133 clientIf=6 device=00:17:E9:C0:86:14
I/mono-stdout(17824): BLEAdapter.OnConnectionStateChange()
I/mono-stdout(17824): Gatt disconnected!
A successful connection attempt to one of those beacons does not have these sets of four bt_osi_alarm and bta_gattc_conn_cback errors. Preferably if someone knows the Android source well, hopefully they can tell me what's going on. It's a long shot I know, but I'm kinda out of options. Thanks.
Some additional information might help the community debug this issue for you. Please add the following to your original question:
Make/Model/Revision of all BLE devices that you've tested and whether or not each one works
Specific android device you have tested with
The error your app gets and at what step it fails
Are you able to get a BluetoothDevice
Does it fail when calling connectGatt()
Is your app written in java/android studio, or is this some kind of universal app that runs on both iOS and Android?
In my experience, alarm expiration too close for posix timers, switching to guns, isn't as serious as its error level suggests. On my nexus 7/marshmallow device, I see this message constantly while connected to a bluetooth device (serial profile, not BLE) so I don't think this is a bug.
I suggest checking up on the BLE device manufacturer to see if there are any firmware upgrades for them too.
More details on alarm expiration too close for posix timers, switching to guns
What's happening is some part of the android bt code is setting a very short timer. So short, that it expires before the app can measure it.
The error, alarm expiration too close for posix timers, switching to guns, was added to android source in a commit 081e4b67b44a5fd397c2d79a5566e11ae52d4aca
The commit message gives us more background on what is happening.
Ensure alarms are called back when they expire in the past
Turns out the posix timers we're dealing with aren't well behaved.
If the timer is TIMER_ABSTIME the following is supposed to be true:
"If the specified time has already passed, the function shall succeed
and the expiration notification shall be made."
But alas, this is not the case. If the expiration time happens to be
in the past (e.g. very short timer which gets hit with a context
switch before the timer can be set) the timer decides to disarm
itself. This means no more callbacks happen, and no more alarms are
processed ever.
sadness.
But thankfully, we can use timer_gettime to check the state of the
timer after timer_settime. If timer_gettime tells us the timer is
disarmed right after we armed it, we want to perform the alarm
callback ourselves.
Put all timer callbacks on the same thread (as would be the case in
the underlying timer implementation already) and used a sempahore to
signal when an alarm expires in the normal posix timer callback and
also in the timer didn't set case.
The code also includes the following comments
If next expiration was in the past (e.g. short timer that got context
switched) then the timer might have diarmed itself. Detect this case
and work around it by manually signalling the |alarm_expired|
semaphore.
It is possible that the timer was actually super short (a few
milliseconds) and the timer expired normally before we called
|timer_gettime|. Worst case, |alarm_expired| is signaled twice for
that alarm. Nothing bad should happen in that case though since the
callback dispatch function checks to make sure the timer at the head
of the list actually expired.
Got a tough one here.
So, we're trying to upgrade an OpenTok video chat application from Flash to WebRTC, and are running into socket errors as we try to implement the 'helloworld' WebRTC sample. The errors occur when we try to do a session.connect() call, not when we request a sessionId or a token. And the error basically looks like this (session_id and partner_id anonymized):
SessionInfo Response:
#document
<sessions>
<Session>
<session_id>asfgdagbasdfovnwoinvcwoinvoiandfvoinvoidnofgfdfgfgivniodfnv-sdfgdfgdfg-</session_id>
<partner_id>1234567890</partner_id>
<create_dt>Sun Sep 01 12:00:45 PDT 2013</create_dt>
<session_status>INFLIGHT</session_status>
<media_server_url>…</media_server_url>
<p2p_server_url>rtmfp://p2p101-oak.tokbox.com:1945/multicast</p2p_server_url>
<media_server_hostname>oms409-oak.tokbox.com</media_server_hostname>
<messaging_server_url>oms409-oak.tokbox.com</messaging_server_url>
</Session>
</sessions>
connectToMessenger
WebSocket error: undefined
TB.Socket Error :: The socket to oms409-oak.tokbox.com received an error: Unknown Error
TB.exception :: title: Connect Failed (1006) msg: TB.Socket Error :: The socket to oms409-oak.tokbox.com received an error: Unknown Error
Any ideas on what might be causing this? We're testing on the latest version of Chrome 29, and it happens in both localhost and on our production servers. So it doesn't seem to be a firewall. The one thing I can think of is that we're running on a Meteor/Node.js framework, which has websockets enabled by default. The code is pretty much boilerplate helloworld sample from the following:
http://tokbox.com/opentok/tutorials/hello-world/js/demo.html
We get the sessionId and token successfully, it's just that the session.connect() doesn't ever happen (and, thus, we can't ever get our connection object or subscribe to the event listeners).
Any ideas on how we might go about debugging this issue?
Thanks in advance for any help!
abigail
In typical fashion, after I spend two days on a bug, get so frustrated that I post a question to StackOverflow, and then figure it out an hour later.
Long story short, the OpenTok account had an 'enable WebRTC' option that wasn't set. It was an account administrator issue. Long story short... make sure devs have access to the accounts the business folks have!
I think you might be using the flash js library instead of the webrtc library. If you had joined your session using flash, it will not be able to work with webrtc.
Here's the webrtc library:
<script src='https://swww.tokbox.com/webrtc/v2.0/js/TB.min.js'></script>
Here is the flash library:
<script src='https://swww.tokbox.com/v1.1/js/TB.min.js'></script>
Think of webrtc and flash as two separate products, they do not interoperate.
I don't have any errors with my smart target application, but I do see in the event log, the following error messages:
ERROR 2012-09-19 14:30:09
com.tridion.smarttarget.utils.AmbientDataHelper - can't find defined
trigger-types in claim store (check if your smarttarget cartridge is
up and running)
and:
ERROR 2012-09-19 14:30:11
com.tridion.smarttarget.tags.TimeoutQueryRunner - The fredhopper query
timed out java.util.concurrent.TimeoutException at
java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source) at
java.util.concurrent.FutureTask.get(Unknown Source) at
com.tridion.smarttarget.tags.TimeoutQueryRunner.executeQuery(TimeoutQueryRunner.java:64)
ERROR 2012-09-19 14:30:11
com.tridion.smarttarget.tags.TimeoutQueryRunner - The fredhopper query
timed out
I would really like to understand what is causing these and how I can remove them. Or some suggested steps to help me debug this would be great :)
As I say, everything is working perfectly, later on in the logs I see the query to ST is correct and the results being generated.
In the event that is helps, I'm running on a 2009 implementation with Smart Target 2010, java 1.5.
thanks
John
Sounds like you might have a trigger configured in ST that does not actually exist in the ADF (or is mismatched). Have you looked through your trigger-types.xml file for anything obvious? Have you disabled an ADF cartridge but not removed the corresponding trigger in the XML perhaps? See the documentation for Defining trigger types.
I think your timeout is coming from the SmartTarget region rather than FredHopper. Sometimes a query that isn't already cached in FredHopper can take a while to return, even though it's ultimately successful. The ST query tag has a timeout (defined in the smarttarget_conf.xml file, or over-ridden with a tag attribute) that it will wait for a response from Fredhopper for before resorting to using the fallback content. This might explain why you see later in the logs that the query is correct and that results are returned. See the documentation for <tcdl:query>.
No conclusive answer for you I'm afraid, but I hope that helps.
The first error is logged if your SmartTarget cartridge is not running -- or if the data that it puts into ADF is lost somehow (e.g. you have disabled sessions in your web server).
In that case, SmartTarget will still do a query but it won't include anything from the Ambient Data Framework in it. If you don't have any triggers based on ambient data, the end result is the same for you.
To get rid of the error, make sure that smarttarget_cartridge is configured correctly.
As for the timeout error, it simply means that the query sent to Fredhopper took longer than the configured time. In that case it will show the fallback content instead. If this is happening a lot, you might want to increase the timeout within smarttarget_conf.xml.
I hope you found the issue, but for future reference, the first error message is raised when the claim "taf:claim:ambientdata:definedtriggertypes" is not set by the SmartTarget cartridge. This can be caused by:
SmartTarget cartridge could not load the the trigger types from the SmartTarget server. The log will show an error "can't retrieve list of defined trigger types from FH".
The HTTP session on your web server is expired during an active visit (the HTTP session expired but the browser is still open) and the claim is "lost".
The server does not support sessions like Peter mentioned.