How to set SameSite attribute in Ant Media Server? - webrtc

I'm using Ant Media Server in one of my streaming project. I need to set SameSite=none in Ant Media Server. Could you please tell how to do that?

You need to set the SameSite attribute through context.xml. By default, context.xml file is under /usr/local/antmedia/webapps/{APP}/META-INF/context.xml
Add the following line to set the SameSite to none:
<CookieProcessor sameSiteCookies="none" className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"/>
Then your context.xml file should something like this:
<Context>
<Resources allowLinking="true" cacheTtl="500" className="io.antmedia.webresource.StreamWebRoot"/>
<CookieProcessor sameSiteCookies="none" className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"/>
</Context>
Please pay attention that SameSite=none is available on accessing the secure content. In other words, you need to use HTTPS.
For other SameSite values, please visit to https://tomcat.apache.org/tomcat-8.5-doc/config/cookie-processor.html
To learn more about SameSite attribute, visit the following link
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Related

Prevent sending referrers when clicking links from my site with an exception for one domain

Let's admit that, for security or privacy reasons, I want to globally set my referrer policy to be "no-referrer".
For instance, using Apache's .htaccess's
Header always set Referrer-Policy no-referrer
or IIS' web.config's
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Referrer-Policy" value="no-referrer" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>
In other words, I want this policy to be globally enforced, for every single webpage, and I enforce this policy at the level of the server.
However, for one particular domain (say https://validator.w3.org/), I'd like to send the referrer (for instance, to use the convenient url https://validator.w3.org/check?uri=referer).
I could use the experimental referrerpolicy attribute of links, but I don't know how well is that attribute supported. I don't know either if such an attribute can override the setting of the server.
The link type 'norefferer' attribute seems to be well supported, but I want to achieve the opposite!
How could I globally disallow the referrer to be sent, except for links pointing to a particular domain?
Disclaimer: (a variation of) that question was posted on webmasters.stackexchange.com. Despite a bounty, it had only 100 views in 2 weeks, and only one answer was offered. That answered is more a "proof of concept" than anything else, and does not cover the "does it override the server's configuration?" aspect of the question.
Since the Referrer-Policy: no-referrer header will instruct the user agent not to send a Referer header at all, there is little you can do without touching the delivered content. In a usual scenario, the server has no knowledge what kinds of links the content holds, and the options for Referrer-Policy header only deals with the origin of the request.
The only viable option I come to think is to rewrite content. Since the noreferrer attribute is widely supported you could use Apache's mod_substitute, for instance.
You would need to formulate a suitable regular expression to match links that you want to include the noreferrer attribute to. Something like <a\s+[^>]*href="(http://)?www.google.com[^"]*">will match a tags pointing to google homepage.

Securing Kentico Media Library file from direct URL access

I am trying to prevent unauthorized access to all files within some of my media libraries in Kentico v9.0. I intend to only provide access to certain libraries via Kentico Role membership and global admins only.
I have followed the guide published here: Securing media libraries and it seems to work fine: Direct URL path access results in a 401.2 - Unauthorized message, regardless of user authentication state and role membership. And I have a media gallery web part set up correctly to provide the permanent URLs, which also work as I expect them to.
However, I have another requirement; which is to serve up a ~/googlesitemap.xml file. I followed the guide published here: Google Sitemaps, which instructs me to provide an attribute to the system.webServer/modules node in the web.config:
<modules runAllManagedModulesForAllRequests="true">
...
</modules>
However, when I add the above, then any authenticated user can gain access to my media library files if they enter in the full URL. This violates my attempts at media library access based on role membership; since I dont want users in other roles to be able to get at the files.
I have tried to exclude all media library files from the re-writing engine by adding my media folder root as an Excluded URL in Settings > URLs and SEO > URL Format > Excluded URLs... but this doesn't appear to help.
Any suggestions would be highly welcome!
As far as I know runAllManagedModulesForAllRequests attribute is mandatory only for different extensions (different from .aspx). If you are using IIS 7 or above you can omit this attribute in your web.config (see source).
Note: In ASP.NET websites, the value of runAllManagedModulesForAllRequests previously had to be set to true to support routing. However, once IIS 7 has been updated with a Service Pack, the value of runAllManagedModulesForAllRequests can be set to false or omitted when working with ASP.NET routing. For more information, see ASP.NET Routing on the MSDN website.
So quick fix: Do not add this attribute to web.config and your media gallery (permissions) should work as you wish.
EDIT: So I think I have got solution for you. It seems that runAllmanagedModulesForAllRequests attribute kills Anonymous Authentication setting so Kentico serves data after successful authentication. I`ve found workaround so you can forbid access to media library. Try to add something like:
<location path="MySite/media/MyMediaLibrary">
<system.web>
<authorization>
<deny users="*"/>
</authorization>
</system.web>
</location>
into your web.config inside configuration section.

Set and check STS Header is present

I have (hopefully) set apache to issue an STS header for all HTTPS traffic as described in How to set HSTS header from .htaccess only on HTTPS
I was hoping to be able to verify that this was working by looking at the response header in chrome dev tools but there doesn't seem to be anything in there related to it:
Is there a way to check that this is functioning correctly? Any help much appreciated.
You can check this is working correctly by looking for the strict-transport-security header in the response headers (in the dev tools where you have taken your screenshot).
If you try the same request you've made with the dev tools with https://accounts.google.com/, for example, you should see an entry like this:
strict-transport-security:max-age=10893354; includeSubDomains
You were already on the right track, but there's probably something wrong with the way you've configured your server.

Removing p_auth in liferay header (But not disabling the authentication check)

Is there a way to remove the p_auth in the POST header, but still having it in the body? I still required the authentication check, therefore disabling it is not the option. Thanks
I know that this is an old question but there is no answer yet. You should enable friendly url mapping in Liferay. This involves creating a xml config file describing the url patterns and routes. You can find some information on it here.
Once it is enabled you can specify the p_auth parameter to be hidden from the url.

Magento Rest API Oauth URL Returning 404

From the Magento wiki at:
http://www.magentocommerce.com/api/rest/authentication/oauth_authentication.html#OAuthAuthentication-OAuthProcess
When getting an API token you start off by getting an Unauthorized Request Token at:
www.mystore.com/oauth/initiate
However, my code does not work and when I browse to the above url in my browser I get a 404.
I am appending shop store code to the base url (eg www.mystore.com/en/) I don't know if this alters anything.
The Magento Wiki has a typo:
$adminAuthorizationUrl = 'http://yourhost/admin/oAuth_authorize';
Should be:
$adminAuthorizationUrl = 'http://yourhost/admin/oauth_authorize';
I struggled with this one for most of the day, so here's a late contribution in case it helps anybody:
The authorization URL that's documented by Magento, admin/oauth_authorize, assumes that you're not using a custom URL for your admin access. "admin" is the standard URL to access the Magento dashboard, but many people change it for security. If you have changed your admin URL to something other than "admin", use that instead.
IOW if you access your Magento dashboard at https://yoursite.com/foo, then your authorization URL is foo/oauth_authorize.
I also had the problem, that the following request returned the 404 http status:
http://yourmagentostore.com/oauth/initiate
The solution was quite simple: In case if you are using multiple stores and/or store views on the same domain, don't forget to add the url path which maps to the store view. E.g.
http://yourmagentostore.com/<my-store-view-path>/oauth/initiate
I just had the same problem. Not many similar problems to be found and no solution. This is strange because this seems to be a missing config option 'global/request/direct_front_name', which isn't set in Core/Oauth module. How can all the tutorials work without this important setting!?
Without "oauth" setting being there, every call to /oauth/[controller] leads to "noRouteAction" being resolved (see. Mage_Core_Controller_Request_Http::setPathInfo() and Mage_Core_Controller_Request_Http::isDirectAccessFrontendName($storeCode)) instead of default indexAction.
So, the solution is to set this setting in local config or an own extension as follows
<?xml version="1.0"?>
<config>
[...]
<global>
[...]
<request>
[...]
<direct_front_name>
<oauth/>
</direct_front_name>
</request>
</global>
</config>
Afterwards you can finally get the token at least. I'm checking the further process now.
There is one subtlety don't forget the http:// so your call to the store should be
http://yourmagentostore.com/oauth/initiate
Also there is more to REST services setup then on the link you posted, it is only an overview. There is a ton of configuration on the store before you will actually get a rest response and when the user isn't recognized, unauthorized or without proper ACL privileges you will get 404 or 500 responses. I guess that deters hackers but it is a bear to trouble shoot. I've been down this road and although I am using an automation tool the Setup of the store and troubleshooting is the same.
Take a look on my blog I keep it up to date with my adventures with the Magento REST API
Cheers!
Rich Borek
http://magento-simplified.blogspot.com