My capstone team has decided to use Qooxdoo as the front end for our project. We're developing apps for OpenFlow controllers using NOX, so we're using the NOX webservices framework. I'm having trouble getting data from the service; I know the service is running because if I go to the URL using Firefox the right data shows up. Here's the relevant portion of my code:
var req = new qx.io.remote.Request("http://localhost/ws.v1/hello/world",
"GET", "text/plain");
req.addListener("complete", function(e) {
this.debug(e.getContent());
});
var get = new qx.ui.form.Button("get");
get.addListener("execute", function() {
alert("The button has been pressed");
req.send();
}, this);
form.addButton(get);
In the firebug console I get this message after I click through the alert:
008402 qx.io.remote.Exchange: Unknown status code: 0 (4)
And if I press the Get button again I get this error:
027033 qx.io.remote.transport.XmlHttp[56]: Failed with exception: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIXMLHttpRequest.open]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame :: file:///home/user/qooxdoo-1.0-sdk/framework/source/class/qx/io/remote/transport/XmlHttp.js :: anonymous :: line 279" data: no]
I've also looked at the Twitter Client tutorial, however the "dataChange" event I set up in place of the "tweetsChanged" event never fired. Any help is appreciated, thank you.
This sound like a cross domain request issue. qx.io.remote.Request uses XHR for transporting the data which may not work in every case due to the browser restriction. Switching the crossDomain flag on the request to true will change from XHR to a dynamically inserted script tag doesn't have the cross domain restriction (but other restrictions).
req.setCrossDomain(true);
Maybe that solves your problem.
Additionally, you can take a look at the documentation of the remote package to get some further details on cross domain requests:
http://demo.qooxdoo.org/current/apiviewer/#qx.io.remote
Also take care not to use a request object twice. The only work once.
Related
I'm getting a browser error when using SustainSys.Saml2 library with my app:
400 Bad Request
Request Header Or Cookie Too Large
nginx/1.14.0
I think that reducing my cookie size might help and I only really need the email from the claim data, so I thought that if I could just save the email claim and remove the other claims, that it might reduce my cookie size and fix this error.
I read the response to a similar question (SustainSys.Saml2 Request length header too long) and looked for some information on how to implement AcsCommandResultCreated to remove unused claims (and hopefully reduce cookie size). I didn't find a lot of documentation, but did piece together some ideas and code to try and take a stab at it.
I've tried this code in my global.asax as well as in a controller action (that I made the "returnUrl" after Saml2/Acs). It doesn't look like my FedAuth cookie (set by Saml2/Acs) is any smaller. Any comments or suggestions? Thank you.
// Check if email claim exists
var principal = ClaimsPrincipal.Current;
var userEmail = principal.Claims.FirstOrDefault(claim => claim.Type == ClaimTypes.Email)?.Value;
// Create new command result that only contains the email claim
if (userEmail != null)
{
var emailClaim = principal.Claims.FirstOrDefault(claim => claim.Type == ClaimTypes.Email);
Sustainsys.Saml2.Configuration.Options.FromConfiguration.Notifications.AcsCommandResultCreated =
(commandResult, response) =>
{
var newCommandResult = new Sustainsys.Saml2.WebSso.CommandResult();
newCommandResult.Principal.Claims.Append(emailClaim);
commandResult = newCommandResult;
};
}
UPDATE:
It turned out that the test environment that I was using (which used nginx) needed to increase the request header buffer size. Adding these cookies increased the size to around 9500 bytes and nginx by default has a request header buffer size that is lower than that (I think 8000). Contacting the code owners of the test server running nginx, and increasing this solved my problem, without me having to reduce my cookie size.
Do you have a lot of failed authentication attempts? That can leave a lot of Saml2.XYZ correlation cookies around on the domain. Try checking the browser dev tools and clean those up.
The "headers too large" is usually something that happens when a user has tried signing in several times with a failure and those cookies get stuck. The real issue is usually something else - causing the authentication to fail and those correlation cookies to be accumulating.
The issues are when I am trying to run federated authentication with the help of amplify auth method on the browser it works fine, but when I try to run it on my mobile.
It throws error No user found when I try to use Auth.currentSession() but the same work on the browser.
tried to search about this type of issue but I found related to ionic-cordova-google-plugin not related to AWS Amplify Federated Login Issue.
Updating the question after closing the question with less debugging information without asking for any information.
This is issues raised in git hub with respect to my problem.
Issue No. 5351 amplify js it's still in open state.
https://github.com/aws-amplify/amplify-js/issues/5351
Another issue 3537 which is still in Open
These two issues has the same scenario like me, I hope its enough debugging information, if more required mention comment instead of closing without notification, it's bullying for a beginner not helping
I fixed the above problem by referring a comment or wrapped around fix.
Link that will take to that comment directly link to comment.
First read the above comment as it will give you overall idea of what exactly the issue is instead of directly jumping to the solution.
Once you read the comment you will be little unclear with respect to implementation as he has use capacitor and not every one are using capacitor.
In my implementation I ignore this part as I am not using capacitor.
App.addListener('appUrlOpen')
Now lets go to main step where we are fixing this issue, I am using deep links to redirect to my application
this.platform.ready().then(() => {
this.deeplinks
.route({
"/success.html": "success",
"/logout.html": "logout",
})
.subscribe(
(match: any) => {
const fragment = JSON.stringify(match).split('"fragment":"')[1];
// this link can be your any link based on your requirement,
// what I am doing it I am passing all the data which I get in my fragments.
// fragments consists of id_token, stage, code,response type.
// These need to be passed to Ionic in order for Amplify to run its magic.
document.location.href = `http://192.168.1.162:8100/#${fragment}`;
},
(nomatch) => {
console.log("Got a deeplink that didn't match", nomatch);
}
);
});
I got this idea by referring the issue in which the developer mentioned of sending code and state along with application deep linking URL.
Randomly today my powerbi embedded code has been throwing:
DOMException: Failed to execute 'atob' on 'Window': The string to be decoded is not correctly encoded.
at window.atob (eval at <anonymous> (https://app.powerbi.com/13.0.11674.244/scripts/reportembed.externals.bundle.min.js:1326:504), <anonymous>:1:83)
at e.parsePowerBIAccessToken (https://app.powerbi.com/13.0.11674.244/scripts/reportEmbed.min.js:1:2331307)
at e.isTokenTenantValid (https://app.powerbi.com/13.0.11674.244/scripts/reportEmbed.min.js:1:2331046)
at t.isPowerBIAccessTokenValid (https://app.powerbi.com/13.0.11674.244/scripts/reportembed.bundle.min.js:21:31523)
at t.promptForLogin (https://app.powerbi.com/13.0.11674.244/scripts/reportembed.bundle.min.js:21:31233)
at m.scope.promptForLogin (https://app.powerbi.com/13.0.11674.244/scripts/reportembed.bundle.min.js:21:25515)
at fn (eval at compile (https://app.powerbi.com/13.0.11674.244/scripts/reportembed.externals.bundle.min.js:1444:307), <anonymous>:4:374)
at m.$digest (https://app.powerbi.com/13.0.11674.244/scripts/reportembed.externals.bundle.min.js:1350:310)
at https://app.powerbi.com/13.0.11674.244/scripts/reportEmbed.min.js:1:1626830
at t.i [as _next] (https://app.powerbi.com/13.0.11674.244/scripts/reportEmbed.min.js:1:189984)
I checked the access token and they appear valid. (No different to the ones working yesterday). I added a debug hook into window.atob and it seems like something inside of parsePowerBIAccessToken is passing undefined to atob. I can't figure out why though unless this code changed.
Kind of stuck on how to figure out the issue. (Not helping that Chrome seems to struggle to debug the lines without crashing).
The code path is trying to run the embed token through this code:
e.prototype.parsePowerBIAccessToken = function() {
return JSON.parse(atob(i.powerBIAccessToken.split(".")[1]))
}
Odd because the code is clearly using "tokenType: models.TokenType.Embed," and thus probably shouldn't be going down that code path?
I noticed it works if I'm logged into the MS account though, so it's using cookies.
If you copy and paste the embed URL from a report it'll have autoAuth=true in the URL. You must remove this from the embed URL or it attempts to use your cookies to authenticate. (It'll also try to use the embed token like an access token and execute wrong code, so that's MS's bug).
In my JS code I removed the autoAuth from the embed url and it'll skip trying to use cookies.
embedURL = embedURL.replace(/autoAuth=true&/ig, '');
You should always get the embed URL using the REST APIs.
From the embed for your customers (Embed Token) documentation
using Microsoft.PowerBI.Api.V2;
using Microsoft.PowerBI.Api.V2.Models;
// You need to provide the workspaceId where the dashboard resides.
ODataResponseListReport reports = await client.Reports.GetReportsInGroupAsync(workspaceId);
// Get the first report in the group.
Report report = reports.Value.FirstOrDefault();
// Generate Embed Token.
var generateTokenRequestParameters = new GenerateTokenRequest(accessLevel: "view");
EmbedToken tokenResponse = client.Reports.GenerateTokenInGroup(workspaceId, report.Id, generateTokenRequestParameters);
// Generate Embed Configuration.
var embedConfig = new EmbedConfig()
{
EmbedToken = tokenResponse,
EmbedUrl = report.EmbedUrl,
Id = report.Id
};
You get the embed URL from the Report object.
The URL you got from powerbi.com is powerbi secure embed and it is not recommended to use this URL for another scenario.
We raised this issue with the PowerBI team. You are supposed to use an API call to get the embed URL for a report. There is an API tester here: https://learn.microsoft.com/en-us/rest/api/power-bi/reports/getreportingroup
Here is a playground for testing embedding: https://microsoft.github.io/PowerBI-JavaScript/demo/v2-demo/index.html
TL;DR: Added custom location type to environment.js then ember serve -> open browser to route /foo -> cannot GET /foo
Followed the instructions at https://www.emberjs.com/api/classes/Ember.Location.html#toc_custom-implementation and copied the code exactly as it appeared into a file called app/locations/history-url-logging.js, added a line to config/environment.js that said:
ENV.locationType = 'history-url-logging';
For reference, the code given in the docs is simply:
import Ember from 'ember';
export default Ember.HistoryLocation.extend({
implementation: 'history-url-logging',
pushState: function (path) {
console.log(path);
this._super.apply(this, arguments);
}
});
I decided to restart the server, did the usual CTRL+C to ember s then did ember s again. I went back to my browser sitting on one of the routes, hit F5, and received the cryptic error:
Cannot GET /contacts
So, after MUCH Googling and trial and error (and posting a previous question here which I just edited with this text you're reading), I discovered that to FIX that error, all I had to do remove the config line ENV.locationType = 'history-url-logging';, restart the server (ember s), and suddenly the app worked fine!
What's even more odd is that if I start the app without that line in environment.js, then once the app is running (and the browser window reloads just fine, etc), then I re-add the line that says ENV.locationType = 'history-url-logging'; (which triggers a live reload), and the app still works fine! (E.g. hitting F5 to reload the page doesn't vie me the "Cannot GET /contacts" (or whatever the route is) error.) And, of course, the console gives me the "console.log" output as expected from the code above.
So, long and short of it, using a custom location totally seems to screw up ember serve - which is really sad and frustrating! Any ideas how to fix this?
Ember built-in server looks at the environment.js locationType property to figure out if it must serve routes after the rootURL path. By default, if the locationType is history it will do it. It uses string matching.
In your case you wrote your own location, inheriting from HistoryLocation therefor the locationType property in the environement.js is now history-url-logging. The built-in server doesn't recognize it as a history based form of location just by the name. It will default to hash location. It doesn't analyze your code.
For this scenario, we have to help the built-in server to understand that the locationType is equivalent to a history location.
You need to add historySupportMiddleware: true in your environment.js file right after the locationType property.
I recently switched from using the BlackBerry Facebook SDK jar to using the project's source code (checked out from the tag that the jar was built from).
Ever since this switch, I've experienced BrowserField problems:
On a device, the loading graphics persists until I back out.
On a simulator I see:
Error requesting content for
https://www.facebook.com/dialog/oauth?scope=user_about_me,user_activities,user_birthday,user_education_history,user_events,user_groups,user_hometown,user_interests,user_likes,user_location,user_notes,user_online_presence,user_photo_video_tags,user_photos,user_relationships,user_relationship_details,user_religion_politics,user_status,user_videos,user_website,user_work_history,email,read_friendlists,read_insights,read_mailbox,read_requests,read_stream,xmpp_login,ads_management,user_checkins,friends_about_me,friends_activities,friends_birthday,friends_education_history,friends_events,friends_groups,friends_hometown,friends_interests,friends_likes,friends_location,friends_notes,friends_online_presence,friends_photo_video_tags,friends_photos,friends_relationships,friends_relationship_details,friends_religion_politics,friends_status,friends_videos,friends_website,friends_work_history,manage_friendlists,friends_checkins,publish_stream,create_event,rsvp_event,offline_access,publish_checkins,manage_pages&redirect_uri=http://www.facebook.com/connect/login_success.html&display=wap&client_id=[APPLICATION_ID]&response_type=token
Error message null.
where APPLICATION_ID is my correct application ID.
The above URL opens fine in my PC browser, and I have debugged for a while through the Facebook sdk's source and found nothing.
It is possible that the application id might have changed recently without me knowing, and my next step is to revert back to using the .jar just for testing purposes.
Has anyone seen similar behavior with the BlackBerry SDK before?
I'm not sure if this is what happened in your case, but I've seen that error when the ProtocolController is set before the BrowserField is initialized. Like so:
private BrowserField bf;
...
BrowserFieldConfig bfc = new BrowserFieldConfig();
// bf not initialized yet but no compiler error
bfc.setProperty(BrowserFieldConfig.CONTROLLER, new ProtocolController(bf){
public void handleNavigationRequest(BrowserFieldRequest request) throws Exception {
super.handleNavigationRequest(request);
}
public InputConnection handleResourceRequest(BrowserFieldRequest request) throws Exception {
return super.handleResourceRequest(request);
}
});
bf = new BrowserField(bfc);
add(bf);
bf.requestContent("http://www.google.com");
...
Simply setting the ProtocolController after the BrowserField is initialized but before content is requested solves it.