I need to modify the User-Agent header in an XHR request in my packaged app. When I do so, I get the error:
Refused to set unsafe header "User-Agent"
My app already has full socket access, so I could do it that way. But that would be really, really annoying.
It would be super nice if I were allowed to set this header in packaged apps that already have raw socket access.
Maybe there is some other API or permission that I'm not aware of? webRequest doesn't seem to be relevant here.
It seems unlikely that this will be addressed on the Chrome platform. So when I need to have more control over my XMLHttpRequest, I use my own shim, which I am keeping up to date inside the Web Server for Chrome (github) project. You can see it being used in this example
Related
I run an self-hosted instance of BigBlueButton and signed up for Xirsys TURN server services because we need to serve clients behind (pretty restrictive) firewalls. Before I had been running my own instance of coturn, but as this led to problems recently, I thought I will got someone who does this for a living a try.
Now the configuration in BBB is explained here:
https://docs.bigbluebutton.org/2.2/setup-turn-server.html
Yet so far I completely failed to match the parameters I receive from Xirsys with what I have to put into the /usr/share/bbb-web/WEB-INF/classes/spring/turn-stun-servers.xml file in the place of the <turn.example.com> and <secret_value>.
Did anyone ever make this work? I did try and find a tutorial but also failed.
bbb_web, is returning this the turn uris. passwords to the html5 client, that the client is using in sip.js
so you can either get bbb-web to send valid username/passwords is same method is used, or modify the html5 client to make a Xirsys api call, to get access to the turn candidates.
Would need to look at api docs. twilio has a similar service.
regards,
Stephen
not the most elegant solution but the easiest one for me:
modify the final bbb js bundle to load the stunturn info from a fixed url in
e.g.
/usr/share/meteor/bundle/programs/web.browser/f30716b2b57e2862c4db2325 b7aac63f4622842b.js
the minified part should then look somewhat like:
const r=Meteor.settings.public.media,i='https://<yourbbburl>/html5client/stunturn.json',a=r.cacheStunTurnServers,s=r.fallbackStunServer;
and put either the static credentials or generated ones in a file stunturn.json besides the js bundle.
I have a strange problem whereby any REST APIs relating to SharePoint versions work when testing at design time but generate a 403 Forbidden error at runtime. What is also odd is that all other REST API calls work fine at both design time and runtime and all the parameters are identical to the ones that don't work (headers etc.) and I've done a cut and paste on everything, but still anything relating to versions isn't working, although that might just be a red herring?
The app can successfully delete files and overwrite them, check in and out, etc. so seemingly there are no permission issues. I have also tried checking a file out before reading the version information just in case (as check out is forced before any actions can be carried out on this site) but that didn't work either.
This is an example of one of the calls that is causing the error:
https://mycompany.SharePoint.com/sites/{SiteName}/_api/web/GetFileByServerRelativeUrl('/sites/{SiteName}/Shared%20Documents/{FilenameAndPath}')/version
Look at this post:
https://sharepoint/_api/web/folders/getbyurl('Documents')/files/getbyurl('myfile.docx')/versions?$filter=VersionLabel eq '2.0'
Check the Accept and Content-Type headers in the OnBeforeRequest REST API callback.
I have found that when testing the IDE will send for instance "application/json" for both, but at runtime, the platform adds ";utf-8" to the values of these headers. The requests are then often rejected without a proper error specification/declaration.
I have created a manifest for a Word add-in that refers to a web page that is not secured by https. I get errors in the Word host and can tell Word to temporarily accept this but cannot find how to tell it to ignore the warning on every launch.
It will actually be an issue in the Online versions of Office because the apps themselves are always https, and thus generate mixed content (both http and https) if your app isn't.
Also, it is generally a bad idea to have an unsecured add-in. You're allowing an application to read the documents you're working on, without https you'd never know if you're actually allowing a 'fake add-in' to read all your data and save it somewhere else.
Lastly, the Office store does not allow non-https add-ins at all, so if you're planning in distributing your app through the store you will definitely need SSL.
What are the error that you get in Wordhost? Word does normally not complain when a http:// address is used in a taskpane. Do you maybe have mixed content in the website?
We have restful api over HTTP. Amongst other clients we have also mobile-device clients (e.g. iphone). The issue is that there are several iphone apps in different versions out there (1.0, 2.0). Because they are distributed we don't have control which app-version is calling us.
To identify the app-version on server-side I see following options:
device must append URL parameter (e.g. /foo?iphone-app-version=1.0) : A bit yucky, but good thing is that I can see it always on server-logs (URL is always logged)
we authenticate api-clients with HTTP digest. We could encode the app-version inside the username (e.g. iphone_1_0): Good thing it is logged in server logs, but only works for resources which are exposed as HTTP digest.
device must use custom HTTP-header, e.g. X-IPHONE-APP-VERSION: In my view the cleanest approach, but we don't log HTTP headers in server logs (for log-noise it is switched off). So later analyzation is not possible.
Do you have a preferred approach or any other alternatives?
EDIT: With above versioning I don't mean api-versioning/content-negotiation. It is the version of the mobile-device.
You can use the Accept-Header to allow a client to declare what capabilities it has by identifying what versions of media types it supports. e.g.
mobile app does:
GET /server/foo
Accept: application/vnd.acme.fooappV1+xml
When you introduce new features that are not backward compatible you can tell the new updated clients to send,
GET /server/foo
Accept: application/vnd.acme.fooappV2+xml
Then your server knows the capabilities of the client it is talking to.
You could also get the new clients to do this:
GET /server/foo
Accept: application/vnd.acme.fooappV1+xml, application/vnd.acme.fooappV2+xml
That way you can migrate your server resources over to the new format slowly. If the endpoints deliver application/vnd.acme.fooappV1+xml then the client will revert back to the old way. If the endpoints return application/vnd.acme.fooappV2+xml then the new code can take over.
Using this approach, no URIs need to be changed, so bookmarks and statistics remain valid. Migration to a new format can be done incrementally over time and support for old clients can be gradually phased out.
I decided for custom X-xxx-USER-AGENT one. Main reason to decide against more standard "User-Agent" is that is already "polluted" with http-client library or mobile-device information. A custom X-xxx-USER-AGENT is easier to parse for server and does not intervent http-library which often sets it and could override a custom entry.
The application is simple, an HTML form that posts to a Perl script. The problem is we sometimes have our customers upload very large files (gt 500mb) and their internet connections can be unreliable at times.
Is there any way to resume a failed transfer like in WinSCP or is this something that can't be done without support for it in the client?
AFAIK, it must be supported by the client. Basically, the client and the server need to negotiate which parts of the file (likely defined as parts in "multipart/form-data" POST) have already been uploaded, and then the server code needs to be able to merge newly uploaded data with existing one.
The best solution is to have custom uploader code, usually implemented in Java though I think this may be possible in Flash as well. You might be even able to do this via JavaScript - see 2 sections with examples below
Here's an example of how Google did it with YouTube: http://code.google.com/apis/youtube/2.0/developers_guide_protocol_resumable_uploads.html
It uses "308 Resume Incomplete" HTTP response which sends range: bytes=0-408 header from the server to indicate what was already uploaded.
For additional ideas on the topic:
http://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal
Someone implemented this using Google Gears on calient side and PHP on server side (the latter you can easily port to Perl)
http://michaelshadle.com/2008/11/26/updates-on-the-http-file-upload-front/
http://michaelshadle.com/2008/12/03/updates-on-the-http-file-upload-front-part-2/
It's a shame that your clients can't use ftp uploading, since this already includes abilities like that. There is also "chunked transfer encoding" in HTTP. I don't know what Perl modules might support it already.