I am having issues after I changed the subdomain of my app, it was working the day before but now it doesn't it shows me the message
OneSignal: Could not load iFrame with URL
https://acacito.onesignal.com/webPushIframe. Please check that your
'subdomainName' matches that on your OneSignal Chrome platform
settings.
<script>
var OneSignal = window.OneSignal || [];
var OneSignal = window.OneSignal || [];
OneSignal.push(["init", {
appId: "MyAppID", // copied correctly the UUID
autoRegister: false, /* Set to true to automatically prompt visitors */
subdomainName: 'acacito',
httpPermissionRequest: {
enable: true
},
notifyButton: {
enable: true /* Set to false to hide */
}
}]);
</script>
I have been trying to make it work deleting cookies or any data related that could be stored in the browser and it doesn't work. Also reloading with Ctr+Shift+r, not sure what happens.
At the time of this writing, this error can occur if:
The Site URL in your onesignal.com dashboard settings does not begin with the same URL you're using to access your site.
For example, if your dashboard platform setting's Site URL is http://my-site.com, you have to access your site beginning with the URL http://my-site.com. You can access http://my-site.com/page1, and you can access http://my-site.com/folder/page2, but you have to begin with http://my-site.com. Technically, the Site URL is the origin your OneSignal configuration is allowed to run under, and OneSignal doesn't allow any other site origin from initializing OneSignal with the same subdomain.
For more complicated cases:
If you're developing locally on http://localhost:8181, your Site URL should also be http://localhost:8181 (with the port number).
If you have an alias defined in your hosts file, you still have to use the origin specified in your Site URL. The OneSignal web SDK looks at what's on the address bar and compares it to what's in the Site URL textbox.
The value for subdomainName (in this case acacito) does not match the value you chose in your onesignal.com dashboard settings for Chrome web push.
Just be sure to use the same value.
Related
I tried to fetch the current theme of my NetSuite website and edit it and check it locally, but didn't find the local link.
I didn't get this part, explained on NetSuite Help Center:
To view your customized theme in a browser, navigate to the local version of the application using one of the following URLs:
http://<DOMAIN_NAME>/c.<ACCOUNT_ID>/<SSP_APPLICATION>/shopping-local.ssp
I tried the below links but not working:
http://localhost:7777/c.1234567/scs/shopping-local.ssp
https://domain-name.com/c.1234567/scs/shopping-local.ssp (I try it with my organization id and company domain name)
At localhost:7777 nothing loaded up and at the second link site loaded but without my changes in header.tpl or footer.tpl module files.
The development mode piggybacks off of the live site. Basically the live site has some special .ssp pages that, instead of loading resources from Netsuite, proxy to a service on your local host.
For example if you were running a site at http://www.mynsbasedsite.com
on site that has url root /kilimanjaro then to see your development changes you'd enter the url:
http://www.mynsbasedsite.com/c.<ACCOUNT_ID>/kilimanjaro/shopping-local.ssp
Are you running the local dev service? e.g.
gulp local
If you start that up in the last few lines you should see one or both of these:
+- Local http server available at: http://localhost:7777/
+- Local https server available at: https://localhost:7778/
If you don't see the https reference it's because you haven't created a self signed cert for your local server. Most modern browsers need some coercion to load the either of those.
e.g. when I am testing with Chrome I do the following:
open the staging url and get a blank page
open dev tools and go to the network tab
find checkout.js in red with a failed status
right click and choose 'open in new tab'
see the page warning, click 'Advanced' and click 'Proceed to localhost (unsafe)'
go back to the original tab and refresh.
the versions of SuiteCommerce I'm familiar with use Express under the hood for the local server so any ssl tutorial on Express should include a section on using openssl to generate your key and cert. Once you've created them they go in the root folder of your project and you reference them in the taskConfig section that starts like:
"tasksConfig": {
"local": {
"http": {
"port": 7777
},
"https": {
"port": 7778,
"key": "./key.pem",
"cert": "./cert.pem"
},
"lessSourcemap": false,
"jsRequire": true
},
"configuration": {
After all that navigate to your live site.
This is very strange issue.
After installing the Microsoft Identity Web nuget package and setting up the app with razor pages, when I'm re-directed back to the app following an MS Sign out routine, i find that the logo image is no longer showing on the navbar.
This seems to be happening because the Microsoft Identity Web package is changing the URL of the page after signout i.e. its referencing a signout page that is now provided as part of the baked in package hidden away in one of the MD dll files.
My native javascript code is trying to load the logo image from my Images folder located on the root directory of my wwwroot folder structure, but because the signout page is changing the URL structure by adding a different path reference for the razor page, it's losing the path required for the image, not sure how to fix this?
js code that loads the image:
document.getElementById("navbarLogo").src = 'Images/CompanyLogos/Logo-LightTheme543by140px.png';
This image shows OK when I'm signed in normally or just browsing the site before sign in, so the issue only appears after being re-directed back to the site after an MS Sign out authentication flow.
The error shows 404, indicates that the image is not found, isn't blocked by identity. The image url may in layout, but the sign out page may not refrence the layout correctlly, or the relative path is not set corrcetlly. If it is not the problem, you can share this page code.
In the end I derived up the following solution which gave me what I needed:
// Because I'm using nested folders for the razor pages
// directory then I needed to re-construct the url path to
// to the images folder on wwwroot.
var urlPath = window.location;
var domain = window.location.hostname;
var port = window.location.port;
var baseUrl = 'https://' + domain + ':' + port;
Then using the above:
document.getElementById("navbarLogo").src = baseUrl + '/Images/CompanyLogos/Logo-LightTheme543by140px.png';
Poss not the cleanest solution but still works for me...
We have a Single Page App (SPA) that uses Azure Active Directory "Easy Auth", e.g., the code-less solution. This seems to work ok when users first open the the application. They are redirected to the Microsoft login page and they can authenticate and then access the application.
Then, because its an SPA, users will navigate around and only fire Ajax requests. The problems come approximately 24 hours later when the session cookie expires. Users likely still have the same browser tab open and do not perform a full page refresh. Then they may be working on a record and at some point their next Ajax PUT request fails with a Redirect HTTP status and they loose their work.
So they key question is:
How can we make SPA Ajax requests extend a current user's session so that their session will not expire when they are actively using the application?
It seems like the Azure AD Easy Auth service does not "honor" activity on the part of the user, which leads us to believe that the session cookie never gets updated.
Note: We've recently done some testing with the /.auth/refresh endpoint and this does not solve the problem either.
There are several ways you can possibly solve this. Here are a few that I can think of:
Use local storage: The problem you mentioned is that user's lose their work due to the redirects. The problem of losing work can be solved if you persist the in-progress state in local storage so that it's available when they are redirected back to the page.
Switch to using tokens: The /.auth/refresh endpoint doesn't refresh the AppServiceAuthSession when using AAD because AAD doesn't support refreshing the user information. What you can do instead is authenticate with your backend using the x-zumo-auth tokens. The /.auth/refresh endpoint will correctly refresh these tokens. If you're explicitly logging in users using /.auth/login/aad, then you can add the session_mode=token as a query string parameter. This is done for you if you use the Mobile Apps JavaScript SDK. If login is automatic, then you'll need to add session_mode=token in the additionalLoginParams setting of your auth config. You can then parse the authentication token from the #token fragment which is added to the URL after the login completes.
Use hidden iframes: I haven't tried this myself, but if you can get it working it might require the least amount of code change. The idea is that you use a hidden iframe to re-login the user periodically when you detect they are active. The iframe would need to point to something like ./auth/login/aad?prompt=none&domain_hint={userdomain.com} where {userdomain.com} is the last part of the user's email address - e.g. contoso.com. These parameters get passed to the AAD login page, and the login should complete automatically without any user interaction. Test it manually a few times in a browser window to make sure it works correctly. The result should be an updated auth cookie with a fresh expiration.
Let me know in the comments if you have any questions or issues with any of these options.
Expanding on Chris Gillum's answer with implementation example:
Scenario: Single Page Application (SPA) with Progressive Web App (PWA) capabilities, hosted in Azure Web App. Added authentication using Azure Web Authentication/EasyAuth.
Ran into similar/same issue: Initial loads of the SPA worked fine, but after period of hour(s) (token expires) the app "breaks" - in SPA on iOS tablet that manifested for me with endless whitescreen and seemingly no practical fix (force killing did NOT resolve). Error messages thrown ranged from 401 (understandable) to service-worker refusing to process scripts/handle 302 redirects/etc (less obvious where problem may be).
SPA + Azure Web Authentication/EasyAuth tweaks:
If using MDM, disable "Block Safari navigation menu bar" feature in the MDM for this app. This appears to allow the app to work as expected after force kill (it would reload the page, see expired token, redirect to login and then back to the app). I'm not sure if this behavior is controllable in manifest.json, may be iOS specific capability.
Hidden iframe refreshing of token + Timer/check token periodically (in ajax calls, etc):
Note: As of ~2021-04, Chromium based browser worked with hidden iframe method. For other browsers the AAD page would experience errors and fail - current solution suggested would be storing app state -> navigate to AAD login page with redirect param -> User logs in and redirected back to the app -> App state restored w/ refreshed token.
refreshAuthToken() {
//Chrome based browsers work with silent iFrame based token reAuth
if (this.browserChromium()) {
let domainHint = "contoso.com"; //Domain of your organization users (e.g. me#contoso.com)
//Remove existing iframe (if exists), to minimize history/back button entries
let existingFrame = document.getElementById("authIFrame");
if (existingFrame) {
existingFrame.remove();
}
//Inject iFrame that will call endpoint to refresh token/cookie
console.log("Refreshing auth token (quietly)...");
let iframe = document.createElement("iframe");
iframe.id = "authIFrame";
iframe.style =
"width: 0; height: 0; border: 0; border: none; position: absolute; visibility: hidden;";
iframe.src = `/.auth/login/aad?prompt=none&domain_hint=${domainHint}`;
document.body.appendChild(iframe);
new Promise(r => setTimeout(r, 2000)).finally(() => resolve()); //Hacky method of "waiting" for iframe to finish
} else {
console.log("Refreshing auth token (via page reload)...");
window.location.replace("/.auth/login/aad?post_login_redirect_url=/?restoreData=true");
}
},
//
// Timer example:
//
setInterval(() => {this.refreshAuthToken()}, 1000 * 60 * 5); //Fire every 5 minutes
//
// And/or periodically call this function maintain token freshness
//
checkAuthToken() {
//this.authEnd = JWT from /.auth/me "exp" claim
let now = new Date() / 1000;
let expirationWindow = this.authEnd - 600; // Consider token expiring if 10 minutes or less remaining
if (now >= expirationWindow) {
console.log("Auth Token expired - Refreshing...")
this.refreshAuthToken();
} else {
// console.log("Auth token still healthy.");
}
}
Nicety: Enable anonymous access to PWA icons (if possible). iOS requires icons be publicly accessible when saving PWA to homescreen, otherwise uses screenshot of app rather than formal icon: https://stackoverflow.com/a/67116374/7650275
I am trying to develop a chrome extension that would set the "host" header on certain requests. But the documentation is contradicting as to if the "host" header can be modified or not.
Both of these issues indicate that a) it should not be possible and b) it is impossible
https://code.google.com/p/chromium/issues/detail?id=154900
https://code.google.com/p/chromium/issues/detail?id=158073
Yet multiple extensions in the gallery state they do modify the "host" header.
e.g.
https://chrome.google.com/webstore/detail/header-hacker/phnffahgegfkcobeaapbenpmdnkifigc?hl=en
https://chrome.google.com/webstore/detail/change-http-request-heade/ppmibgfeefcglejjlpeihfdimbkfbbnm
Is it possible to modify the "host" header in the windows version of chrome, and if so how?
Background: I want to be able to test load balanced web instances hitting each host directly via ip address. The "hosts" file is to cumbersome for a large number of hosts. At the moment I use curl to pass the modified "host" header, but I really need the solution in the browser and available for others.
#kzahel was right, and the note about redirection was spot on, here is my basic working code.
chrome.webRequest.onBeforeSendHeaders.addListener(function (details) {
if (details.url.indexOf('toast.txt') <= -1)
return;
details.requestHeaders.push({
name: 'Host',
value: 'testhost:80'
});
return { requestHeaders: details.requestHeaders };
}, {
urls: ['http://*/*']
}, ['requestHeaders', 'blocking']);
chrome.webRequest.onBeforeRequest.addListener(function (details) {
if (details.url.indexOf('sauce') <= -1)
return;
var url = 'http://127.0.0.1/toast.txt';
return { redirectUrl: url };
}, {
urls: ['http://*/*']
}, ['blocking']);
Admittedly a slightly odd example but it goes like this.
My local IIS has a site created that points to a folder that has a file "toast.txt", which is bound to "testhost".
Windows can no way of knowing about "testhost" e.g. cannot ping it.
With the extension running.
Enter the address http://testhost/sauce
The extension notes the "sauce" in the "onBeforeRequest" method and redirects to "http://127.0.0.1/toast.txt" which in turn is picked up on by the "onBeforeSendHeaders" method where the "Host" header is added containing "testhost:80". All this occurs before the request leaves Chrome.
Now IIS receives the request "/toast.txt" that by itself would result in a 404, but because the "Host" header is set it pushes the request to the new website that is bound to "testhost" which then returns the "toast.txt" file.
Phew!
It looks like you shouldn't have difficulty doing this. Use onBeforeRequest
onBeforeRequest: Fires when a request is about to occur. This event is sent before any TCP connection is made and can be used to cancel or redirect requests.
Since this is triggered before any connection to the server is made, you should be able to modify the host header then [edit: if host header is not available, then use a redirect]. Make sure you have the "requestHeaders" permission in the manifest or else you won't see the request headers at all.
Our ASP.NET application pages are deployed as a feature into a MOSS 2007 farm.
When a user logs on to the site the user is directed to a default page.
In the top right corner there is an option "Log on as a different user".
If the user selects this option and enters the credentials of another user, an "Access Denied" message is displayed.
This message does not make sense since all the users have access to this default page. Furthermore, if the user now goes to the address bar and manually changes the URL to the default page, the page loads. I can see in the source part of the "Access Denied" URL that the encoded URL of the target page is the expected default page URL.
Previously, I made a change to the INIT.JS file to redirect the user in the case where the login change is done from a page that is not the default page.
function LoginAsAnother(url, bUseSource)
{
document.cookie="loginAsDifferentAttemptCount=0";
if (bUseSource=="1")
{
GoToPage(url);
}
else
{
var ch=url.indexOf("?") >=0 ? "&" : "?";
//url+=ch+"Source="+escapeProperly(window.location.href);
url+=ch+"Source="+escapeProperly(getSspLocation(window.location.href));
STSNavigate(url);
}
}
The original line is commented out.
The function getSspLocation is just a function I wrote to get the default page URL from any other URL.
function getSspLocation(url) {
var parts = url.split('/');
var result = "";
for (var i = 0; i < parts.length; ++i) {
result += parts[i] + "/";
if (parts[i].toLowerCase() == "ssp")
return result + "default.aspx";
}
return url;
}
Any ideas?
This will not answer your question, but I would advice you against modifying the init.js file. It is both against good practice and against Microsoft's recommendation, you will lose support from them. Furthermore, it will most certainly be overwritten when applying service packs and/or hot fixes.
If you have the need to customize the functionality of OOB script files, do so by deploying a custom master page that incorporates your custom scripts instead.