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!
Related
i am developing an nodejs express application that is running in the ibm cloud. Via Hostedscan i tested my application for security issues.
im getting follwing result:
"X-Content-Type-Options Header Missing"
The Anti-MIME-Sniffing header X-Content-Type-Options was not set to 'nosniff'. This allows older versions of Internet Explorer and Chrome to perform MIMEsniffing on the response body, potentially causing the response body to be interpreted and displayed as a content type other than the declared content type.
Current (early 2014) and legacy versions of Firefox will use the declared content type (if one is set), rather than performing MIME-sniffing.
my url that have a risk:
https://xxx.xxx.xxx.xxx:xxxxx/socket.io/socket.io.js
its a get method
i implemented following solution
(server.js)
const helmet = require("helmet")
.....
app.use(helmet.noSniff())
with this code a part of the security issues where gone like :
https://xxx.xxx.xxx.xxx:xxxxx/
https://xxx.xxx.xxx.xxx:xxxxx
https://xxx.xxx.xxx.xxx:xxxxx/chatroom
but the secuirty risk with https://xxx.xxx.xxx.xxx:xxxxx/socket.io/socket.io.js is still reminding.
i also tryed in my index.html following, because i thought the security risk could be because my client is also interacting with socket.io
<script
src="https://cdnjs.cloudflare.com/ajax/libs/socket.io/4.5.1/socket.io.js"
integrity="sha512-xxxxxxxx....."
crossorigin="anonymous">
</script>
does anyone have an approach?
I've hosted to IIS in Azure a WCF. I need to do a post CORS client side (I'm using dojo js).
I expect this scenario
POST REQUEST -> OPTIONS PRE-FLIGHT -> POST RESPONSE
but if I see the chrome dev tools network I get:
POST Request -> OPTIONS PRE-FLIGHT -> AUTOMATICALLY GET REQUEST -> METHOD NOT ALLOWED (my WCF method only accept POST method)
There also a strange thing, if i see the GET response, it has status code 302 found and in the response header LOCATION : /rest/(X(1)S(xnrhdgei0ecua5s550yxqiv1))/login/ but I don't know what (X(1)S(xnrhdgei0ecua5s550yxqiv1)) is.
How can I solve this problem?
Thank you!
I solved adding <sessionState mode="InProc" cookieless="false"/> into the web.config. See my previous comment for additional details
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
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
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)