'HTMLUnit page not containing 'src' tag
I'm trying to get the link to the .mp4 of this page https://www.clippituser.tv/c/xqbnrq
In Chrome devtools I can see it fine:
<video playsinline="playsinline" webkit-playsinline="" class="vjs-tech" id="vjs_video_3_html5_api" tabindex="-1" preload="auto" autoplay="" src="https://clips.clippit.tv/xqbnrq/360.mp4"></video>
My code is:
Page page = null;
try {
webClient.waitForBackgroundJavaScript(5000);
page = webClient.getPage(url);
} catch (IOException e) {
e.printStackTrace();
}
DomNodeList<DomElement> source = ((HtmlPage) page).getElementsByTagName("video");
String videoUrl = source.get(0).getAttribute("src");
source.get(0).asXml() is the same apart from missing src where the .mp4 is:
<video playsinline="playsinline" webkit-playsinline="" class="vjs-tech" id="vjs_video_3_html5_api" tabindex="-1" preload="auto" autoplay="autoplay"/>
This code works fine for getting videos from other websites so not sure what I'm doing wrong.
Solution 1:[1]
At first - webClient.waitForBackgroundJavaScript(5000); is not an option. You have to call this AFTER retrieving the page.
As of HtmlUnit 2.61.0 there is a bug in the XMLHttpRequest handling, that leads to an ArrayIndexOutOfBounds exception. This is now fixed and a new Snapshot version will be available soon.
But after the fix the page still reports
VIDEOJS: "ERROR:" "(CODE:4 MEDIA_ERR_SRC_NOT_SUPPORTED)"
No compatible source was found for this media.
{"code":4,"message":"No compatible source was found for this media."
Looks like there is some js code that checks the 'browser' to figure out if the video is playable before adding the source. But the js code for the page is complex, it is not that easy to figure out which check fails.
If you like to get this also fixed, please open an issue for HtmlUnit at github and try to isolate the problem (https://htmlunit.sourceforge.io/submittingJSBugs.html).
Solution 2:[2]
WordPress plugin or theme developers cannot use php's session subsystem as you have discovered.
If you need to save some kind of global context for your plugin to work, use WordPress's add_option() function to save it at the end of each operation. You can retrieve your context using get_option().
If you need per-user context, use add_user_meta() to save it and get_user_meta() to retrieve it. Like this:
$id = get_current_user_id();
$myContext = get_user_meta( $id, 'my_plugins_meta_tag_name' );
...
add_user_meta( $id, 'my_plugins_meta_tag_name', $myContext);
WordPress uses a database table to store these sorts of options. Some sites put an object cache in front of the table. But these APIs are how you do what you want to do.
In your plugin's deactivation hook, please consider calling delete_option() to clean up that storage. And, if you use per-user context, please consider using delete_user_meta() to remove your user_meta item from all of them.
$users = get_users( array( 'fields' => array( 'ID' ) ) );
foreach($users as $user){
delete_user_meta ( $user->ID, 'my_plugins_meta_tag_name' );
}
As for sensitive information, WordPress offers no other place to put it. And, if you were using sessions, php would need to put it somewhere as well. By default, php puts session data in the filesystem of the server. That's why WordPress hashes user passwords before storing them.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | RBRi |
| Solution 2 |
