I get some video files from server and use in templates like this:
<div class="player-block" ng-if='hasSubscription(episode_detail.season)'>
<video ng-if='episode_detail' id="serial-video" class="video-js" controls preload="none" height="450" data-setup="{}">
<source ng-src="{{episode_detail.video_mp}}" type='video/mp4'>
<source ng-src="{{episode_detail.video}}" type='video/webm'>
<p class="vjs-no-js">
To view this video please enable JavaScript, and consider upgrading to a web browser that
supports HTML5 video
</p>
</video>
</div>
my nginx config:
Thats what i mean, try to rewind video in google chrome:
http://185.143.173.143:8000/media/SPONGEBOB_TRAP_REMIX_KRUSTY_KRAB_Vine_Remix.mp4
The result is not working in chrome rewind , I read that it is necessary to configure the server to return partial content.How do I configure nginx for this?
You have max_ranges set to 0, which will disable Range request handling in nginx. The simplest thing to do would be to remove that max_ranges 0 line. However, that still might not work if the origin (185.143.173.143) does not honor the Range requests.
In order to test if the origin (185.143.173.143) itself supports range requests, you will want to use curl from your nginx machine:
curl -I -r 0-100 http://185.143.173.143/path/to/video
If the Range request worked, the status will be something like 206 Partial Content and there will be a Content-Range header indicating the requested range. The Content-Length should be 101 in this case. If you get a 200 then likely your actual origin itself does not support range requests, and you will have to debug the configuration there.
Related
I'm attempting to send a POST request to my Google Analytics 4 property directly from Postman. My current request looks like so:
However, when I attempt to send this request I am met with the following output:
<a href=//www.google.com/> <span id=logo aria-label=Google></span></a>
<p><b>403.</b> <ins>That’s an error.</ins>
<p>Your client does not have permission to get URL
<code>/mp/collect?measurement_id=G-xxxxx&api_secret=_xxxxxx</code> from this server.
<ins>That’s all we know.</ins>
I'm currently referencing this documentation provided by Google.
Any idea how/why this could be happening? I triple-checked my secret/measurement ids.
Thanks!
I just had the same issue, but this was because I had disabled the host header. You might want to check the headers tab to see if you have enabled the host header. If you don't see the default headers in that tab, click on the button to show the default headers.
I am currently trying to implement this solution here. The solution seems pretty simple and possible since I am the owner of both of the hosts. On mysite1.com I have added the following img tag.
<img src="//mysite1.com.com/cookie_set/" style="display:none;">
On my site2.com (django), I have a view like so:
def cookie_set(request):
response = HttpResponse()
response.set_cookie('my_cookie', value='awesome')
return response
When I release this code live. I get the following error:
Cross-Origin Read Blocking (CORB) blocked cross-origin response https://www.mysite2.com/cookie_set/ with MIME type text/html. See https://www.chromestatus.com/feature/121212121221 for more details.
I thought that maybe if I just added "Access-Control-Allow-Origin" in my view this might fix things, but according the docs here: https://www.chromium.org/Home/chromium-security/corb-for-developers, there's one more consideration:
For example, it will block a cross-origin text/html response requested from a or tag, replacing it with an empty response instead.
Are my assumptions correct? After adding the correct headers should I just change the content-type to something other than text/html?
Ultimately, my final goal is I would like to set a cookie for a different domain that I have control of (ideally without a redirect).
Best solution: use a different tag for this. (i.e. iframe).
The point behind CORB is to prevent certain tags from being used for XSSI data injection So img tags requests should not return text/html, application/json, or xml content types.
So unless the call to img tag really is for capturing the request itself (for referrer tracking, for example), then you get much more versatility by executing in an iframe anyway (like for SSO-redirection workflows).
See also: Setting third party cookie by using 1x1 <img> tag - Javascript doesn't drop cookie
I fixed this for image files by updating the Content-Type metadata under Properties in S3 - image/jpeg for JPEG files and image/png for PNG files.
My application uploads image files via multer-s3 and it seems it applies Content-Type: 'application/x-www-form-urlencoded'. It has a contentType option with content-type auto-detect feature - this should prevent improper headers and fix the CORB issue.
It seems the latest Chrome 76 version update includes listening to remote file URL headers, specifically Content-Type. CORB was not an issue for other browsers such as Firefox, Safari, and in-app browsers e.g. Instagram.
I made a personal website (http://www.soyoungpark.online) using domain bought from GoDaddy and hosted on AWS s3. I set up everything and thought things were working until I put a simple link to my linkedin profile. When I check the network panel, I see that status code is 200 OK but for the response..there is nothing. The code itself doesn't seem to be problematic; it is simple a with href of the desired link. So I am guessing something could be wrong with my AWS s3 settings? Anyone with similar experience?
It's likely that these services include a header option called "X-Frame" that for security prevents them from being loaded within another site:
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object> . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites. Source: X-Frame-Options
This does look to be the case when attempting to view Linkedin per your example:
Refused to display 'https://www.linkedin.com/in/exampleuser' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
That said, applying a target Attribute to each to open in a new tab or window should allow these outside services to be navigated to.
e.g:
<a href="https://www.linkedin.com/in/exampleuser" target="_blank">
I'm trying to create signed urls for an RTMP distribution in Amazon's CloudFront. I have the following working:
Signed URLs for Web distribution (over http and https) - so I know I am able to sign URLs correctly.
Unsigned URLs for RTMP distribution - so I know I have CloudFront and S3 setup properly for RTMP.
Main question - now that I'm trying to get a signed url for RTMP, it never seems to be playable.
Part of the confusion is based on the format of the url (similar to this question). So I don't know if it matters which part of the url I sign - if I sign the whole thing (like my http urls), or if I only sign a portion, and if I include the mp4: prefix in the path.
There seem to be a lot of pseudo-similar questions on Stackoverflow, but they seem to be related to slightly different issues, and not about actually creating a signed url for RTMP.
Unfortunately there are many variations to how a RTMP url can be created, which
caused a large portion of the confusion. The following is the way that I was able to get this to work with Amazon CloudFront. To be clear, this was to be used in a *.SMIL file, so it might be different if you only need a single url.
The S3ObjectSummary object has a key for the file, which might be something like folder1/folder2/video.mp4.
Use the above key, and remove the .mp4 extension.
Sign the url as normal (I used CloudFrontService.signUrlCanned().
In the *.smil file that is generated, set the base reference to rtmp://<CloudFront RTMP Distribution Domain>/cfx/st
In the video element, set the height and width, and in the src attribute, prepend mp4: to the signed url portion.
Here is an example SMIL file.
<smil data-livestyle-extension="available">
<head>
<meta base="rtmp://some-cloud-front-domain.net/cfx/st"/>
</head>
<body>
<switch>
<video height="720" width="1280" src="mp4:<signed portion of video path>" />
<video height="480" width="853" src="mp4:<signed portion of video path>" />
</switch>
</body>
</smil>
With Python/boto3, I've managed to sign media files with the rsa_signer
http://boto3.readthedocs.io/en/latest/reference/services/cloudfront.html#generate-a-signed-url-for-amazon-cloudfront
by signing only the path to the media file.
Let's say you want to stream an S3 bucket media file located at 'videos/test.mp4'
Following the boto3 example from the link above, here's what you can do to serve the file with flowplayer:
signed_url = cloudfront_signer.generate_presigned_url(
'videos/test.mp4', date_less_than=expire_date)
Then in the flowplayer code (Django template syntax):
<div class="flowplayer fp-slim" data-rtmp="rtmp://{{cloudfront_domain_prefix}}.cloudfront.net:1935/cfx/st">
<video>
<source type="video/flash" src="mp4:{{signed_src}}">
</video>
</div>
I'm using Foundation 4 (the Sass version) and most elements have styles applied to them that are coming from a source listed simply as ... When I click on it to see what it is I get the following:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Authorization Required</title>
</head><body>
<h1>Authorization Required</h1>
<p>This server could not verify that you
are authorized to access the document
requested. Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
</body></html>
What is this source? Shouldn't everything be compiled into foundation.css?
Check your server: If you put an image (foo.jpg) in your directory, can you open it and see it in your browser? I don't have enough details to help you (OS, server, ...) but you probably need to look this way. If the file aren't opening, you have problems in your server config or file permission!
(#admins : sorry, it should be a comment but it seems I don't have sufficient rep to reply to the comment)
I just noticed that whenever .. shows up in Inspector the line number shown matches that of thee selector in the .scss file. I have no idea how this works, or what exactly is responsible for this.
Oh! Just figured it out! It was the experimental SASS support feature which I had enabled in Chrome!
Mystery solved.