Trigger.IO CORS Setup - .htaccess

I'm trying to get CORS working on my trigger.io app:
I've got the following setup in my .htaccess
Header set Access-Control-Allow-Headers: "Accept,Origin,Content-Type,X-Requested-With"
Header set Access-Control-Allow-Methods "GET,PUT,POST,DELETE,OPTIONS"
Header set Access-Control-Allow-Credentials: "true"
Header set Access-Control-Allow-Origin "http://localhost:3000,content://io.trigger.forge99d5a0b8621e11e28cc2123139286d0c"
Running the trigger App in the web (localhost:3000) works fine.
But when I deploy it to an (android) device I see the following error in the debug output:
[ERROR] XMLHttpRequest cannot load {link}http://mydevtest.lan/api/auth/currentuser.{/link} Origin content://io.trigger.forge99d5a0b8621e11e28cc2123139286d0c is not allowed by Access-Control-Allow-Origin. -- From line 1 of null
I'm fearing that setting content:// in the Access-Control-Allow-Origin header is not legal.

The Access-Control-Allow-Origin header as you have it is invalid. Valid values are either '*', or a space separated list of origins. One of the following should work:
Header set Access-Control-Allow-Origin "*"
or
Header set Access-Control-Allow-Origin "http://localhost:3000 content://io.trigger.forge99d5a0b8621e11e28cc2123139286d0c"
Note that I've never tested the latter form (with multiple origins). While the CORS spec allows it, browsers may not yet support it.
One other thing you could do is read in the value of the Origin header, validate it on your server (i.e. manually check that the value equals either "http://localhost:3000" or "content://io.trigger.forge99d5a0b8621e11e28cc2123139286d0c"), and then echo only that value in the Access-Control-Allow-Origin response header. However this requires a little more work since it introduces some server-side conditional processing.

I also fear that content:// is not allowed in CORS, could you try setting Access-Control-Allow_origin to *, if that works then that is probably the problem.
A better solution would be to avoid doing XHR requests and use forge.request.ajax which will make the request from native code and avoid any cross domain restrictions. You can find the documentation for that here http://docs.trigger.io/en/v1.4/modules/request.html#modules-request

Related

load pdf in javascript error, but why directly in browser successfully

all.
I am thinking about a issue using pdfTron SDK(an SDK help load pdf) in my application. This SDK is able to load local pdf files, working like a charm. I decide to load an online pdf file in my web application, using pdfTron SDK, e.g. 'https://cdn.mendix.tencent-cloud.com/documentation/developerportal/tencent-deploy.pdf'. This file is accessible in browser, directly, but when I use scripts, like:
instance.UI.loadDocument('https://cdn.mendix.tencent-cloud.com/documentation/developerportal/tencent-deploy.pdf');
};
I directly got an error when running the application, which shows
Request URL: https://cdn.mendix.tencent-cloud.com/documentation/developerportal/tencent-deploy.pdf
Request Method: HEAD
Status Code: 403
Referrer Policy: strict-origin-when-cross-origin
I think this is a CORS issue. But I cannot understand why I can use browser getting this file, while scripts does not. How can I resolve this? Thanks
I would suggest to read the documentation on pdfTron concerning "webview" and "loadDocment".
WebView is used to get the pdf you want to use from any source(file or web), in your case, you need to use "initialDoc" property, that is where you would place "cdn.mendix.tencent-cloud.com/documentation/developerportal/…".
Then "instance.UI.loadDocument" is used to identify the html element where you want to place the fetched document.
Sample
API Docs
I also try a CORS config in my document server(nginx), like this:
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';
This works now. But It seems that if the document server is not yours, you cannot do this. Hope this help!

Videogular2 gives cors error for Azure DRM protected content

I am using Videogular2 for azure content playback. The contents hosted on azure without DRM works perfectly. When I implement DRM protected content having token authentication gives CORS error. The error is thrown while fetching license from license server.
Following is my code
stream = {
source: 'http://xxxxx.streaming.mediaservices.windows.net/xxxxxxx/abc512kb.ism/manifest(format=mpd-time-csf)',
licenseServers: {
'com.widevine.alpha': {
serverURL: 'https://xxxxxx.keydelivery.westindia.media.azure.net/Widevine/?KID=xxxxx-ef40-87ed-b348-xxxxxx'
}
},
token: 'Bearer xxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
}
<video #media
[vgMedia]="media"
[vgDash]="stream.source"
[vgDRMLicenseServer]="stream.licenseServers"
[vgDRMToken]="stream.token"
id="singleVideo"
preload="auto" crossorigin
>
</video>
I got following error while fetching license from license server.
Response to preflight request doesn't pass access control check: The
value of the 'Access-Control-Allow-Origin' header in the response must
not be the wildcard '*' when the request's credentials mode is
'include'. Origin 'http://localhost:4300' is therefore not allowed
access. The credentials mode of requests initiated by the
XMLHttpRequest is controlled by the withCredentials attribute.
If I run it with disable-web-security of chrome then I call works perfectly.
Did any one face such issue while playing content from Azure Media.
Mandar -- Azure Media Services (AMS) origin sets the value of the 'Access-Control-Allow-Origin' header in preflight response as the wildcard ''. This works well with most players including our Azure Media Player, Roku and JW, and others. From the error, it seems Videogular2 does not work with AMS origin URL since, with credentials mode set to “include”, XMLHttpRequest in their dashjs does NOT allow wildcard “” as the value of “'Access-Control-Allow-Origin”.
Are you running the player from a single domain? If you are, we can set the request to include your incoming origin domain instead of the wildcard. Reach out to me at dwgeo at microsoft dot com and we can enable the feature on your account. Thanks.
I'm faced the same problem. Here is the Videogular2 source https://github.com/videogular/videogular2/blob/master/src/streaming/vg-dash/vg-dash.ts#L70
It work fine on same domain, but for different domain withCredentials=true is missing. after creating player on 70th line
this.dash = dashjs.MediaPlayer().create();
Should go this
this.dash.setXHRWithCredentials(true);
I hope it might help

Mapbox: How to solve CORS issue in map.addSource()

I'm currently trying the Mapbox examples and notably this one.
When the example tries to get the GeoJSON points from the following code:
map.addSource("earthquakes", {
type: "geojson",
// Point to GeoJSON data. This example visualizes all M1.0+ earthquakes
// from 12/22/15 to 1/21/16 as logged by USGS' Earthquake hazards program.
data: "https://www.mapbox.com/mapbox-gl-js/assets/earthquakes.geojson",
cluster: true,
clusterMaxZoom: 15, // Max zoom to cluster points on
clusterRadius: 20 // Use small cluster radius for the heatmap look
});
I get the following error:
Blocking a Cross-Origin Request: The "Same Origin" policy does not
allow you to view the remote resource located at
https://www.mapbox.com/mapbox-gl-js/assets/earthquakes.geojson .
Reason: The CORS "Access-Control-Allow-Origin" header is missing.
I saw about similar problems what to add in http header but how to do it here?
This is up to mapbox. Their server is saying the origin from which you are querying this is not allowed by policy (check headers in the options request). Because their policy isn't supporting the Access-Control-Allow-Origin header, any requests made by XHR to mapbox.com must come from mapbox.com.
Now you could conceivably get around this by using a proxy server on a local VM to pretend you're on mapbox.com - using a HaProxy container, for example, on Virtual Box - and in its config setting up an ACL that points certain requests to mapbox.com to your code and the rest to mapbox.com's IP address. You would then use /etc/hosts to pass requests to mapbox to your VM instead and handle it from there. This is not a simple solution, I just thought it worth pointing out that it's possible.

Error posting to IBM Connections 4.5 activity stream

Using a browser REST client to POST to the activity stream at e.g.
https://connectionsww.demos.ibm.com/connections/opensocial/basic/rest/activitystreams/#me/#all
...with the settings prescribed in IBM Connections OpenSocial API > POSTing new events
...results in the following response:
<error xmlns="http://www.ibm.com/xmlns/prod/sn">
<code>403</code>
<message>You are not authorized to perform the requested action.</message>
<trace></trace>
</error>
What am I missing?
This same approach works nicely on IBM Connections 4.0.
Which setting needs 'switching on'?
Try a URL like this... https://sbtdev.swg.usma.ibm.com:444/connections/opensocial/basic/rest/activitystreams/#me/#all
I added the Basic/Rest component, and it worked for me.
1 - Added URL https://sbtdev.swg.usma.ibm.com:444/connections/opensocial/basic/rest/activitystreams/#me/#all
2 - Changed Method to Post
3 - Added Content-Type: application/json
4 - Authentication -> Basic
5 - Logged IN
6 - Posted
Same thing here: 403 when I make an AJAX call to an IBM Connections 6.0 REST API url. Same error in Chrome, Firefox and IE11. When I open the same URL in a separate browser tab, everything works fine.
Comparing the http headers of both calls, and fiddling with Postman, the diference is the presence and value of the atribute Origin.
Seems that Connections allows calls from its own server. For example, when: Origin: connections.mycompany.com.
It also allows calls when Origin is not defined, which happens when the url is called from a separate browser tab.
There is a doc at IBMs Support site that confirms this - http://www-01.ibm.com/support/docview.wss?uid=swg21999210. It also suggests a workaround that did the job for me: unsetting the Origin attribute in the IBM HTTP Server that is in front of your Connections instance. Add the lines below to the httpd.conf file:
Header unset Origin
RequestHeader unset Origin

How to avoid a XSP/Domino Cross-Site Scripting Vulnerability?

It seems possible to inject javascript in a get request, when refering to the /xsp/.ibmmodres/ XSP/Domino resources.
Normally, when you try this at .nsf/ resources, you get a correct default or custom errorpage without XSS possibilities. Special characters are substituted.
Example:
- http://[server]/[path]/[dbname].nsf/%3Cscript%3Ealert%28document.cookie%29%3C/script%3E
Result:
HTTP Web Server: Cannot find design element
But refering to the /xsp/.ibmmodres/ resources, it yields XSS possibilities.
Example:
http://[server]/[path]/[dbname].nsf/xsp/.ibmmodres/%3Cscript%3Ealert%28document.cookie%29%3C/script%3E
Result:
I get a 404 errorpage "Cannot load unregistered resource /"
And it executes CSJS and shows for example DomAuthSessID !!
How is this possible?
Is there a way to avoid this?
Please help!
Here is an article about how to avoid this:
http://www.wissel.net/blog/d6plinks/SHWL-8XS3MY
Check your Domino version. It should be fixed in 8.5.3. FP2 (not fully sure about that) (but definitely 9.0 Beta).
Other than that follow my instructions and create some web rules:
Type of rule: HTTP response headers
Incoming URL pattern: */xsp/.ibmxspres/*
HTTP response codes: 404
Expires header: Don't add header
Custom header: Content-Type : text/plain (overwrite)
Type of rule: HTTP response headers
Incoming URL pattern: */xsp/.ibmmodres/*
HTTP response codes: 404
Expires header: Don't add header
Custom header: Content-Type : text/plain (overwrite)

Resources