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.
Related
I followed instructions to set up swagger documentation for my existing node API using swagger-jsdoc.
The swagger.json is being served correctly and I added a path to it in the url parameter of the SwaggerUiBundle in index.html like this:
const ui = SwaggerUIBundle({
url: "https://my.domain:5292/swagger.json",
dom_id: '#swagger-ui',
presets: [
SwaggerUIBundle.presets.apis,
SwaggerUIStandalonePreset
],
plugins: [
SwaggerUIBundle.plugins.DownloadUrl
],
layout: "StandaloneLayout" })
However, the first thing it tries to do when opening the page in the browser is showing the default http://petstore.swagger.io/v2/swagger.json instead of my swagger.json. It actually fails to do so because I'm serving the page through https and the petstore is not https but that's a different matter...
Inputing my address to the swagger.json manually into the form on the page works as expected. It shows the API page correctly and validates it. However, I don't want to always re-enter the address there and would like to have it as a default.
Swagger UI 3.0.9 had a bug where it ignored the url parameter and always opened Petstore.
It was fixed in 3.0.10.
I had been having this issue lately when deploying using docker. Tried everything from changing all instance of petstore to my own api json docs but to no avail.
Finally I found out about API_URL environment variable, set it to my api docs in DockerFile and voila!
Took me two days but it was great to see it finally working.
You can disabled default url by adding below configuration in application.property file
springdoc.swagger-ui.disable-swagger-default-url=true
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.
Hi I have done with following steps to implement Universal Link for IOS.
1.My sub domain is npd.nowconfer.com, and my apple-app-site-association file contains,
{
"applinks": {
"apps": [],
"details": [
{
"appID":"R3UDJNSN2P.com.sampleUniversal.teledna",
"paths": ["*"]
}
]
}
}
this file is uploaded into my subdomain npd.nowconfer.com and its serveing over https.
2.I tested using AASA Validator i.e https://branch.io/resources/aasa-validator/#resultsbox and i got Test result as all pass.
you can see attached screenshot.
3.Now In app side,my colleague did configuration such as
Added the domain to Capabilities i.e applinks:nowconfer.com and applinks:npd.nowconfer.com
Handled Universal Links in app i.e in delegate like this
- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray *))restorationHandler {
NSURL *url = userActivity.webpageURL;
// handle url
}
4.my universalink is https://npd.nowconfer.com:5000/calendar/deeplink?url=nowconfer when i click on this link from email ,my app is not opening instead it is redirecting to app store(becasue server side request came handling to redirect app shore if app is not installed on device)
But when i tested universalink validator here https://search.developer.apple.com/appsearch-validation-tool ,i have got some error
Link to Application : Error no apps with domain entitlements
The entitlement data used to verify deep link dual authentication is from the current released version of your app. This data may take 48 hours to update.
I have seen lot of tutorials but not used anything for me.Can you guys help me to figure out what is happening here?
Universal Links have to be standard http:// or https:// links. This means they need to use the standard web ports, of which 5000 is not one. That is why your link is not working — it's not actually a valid Universal Link.
The Apple validator checks for some additional things, and is also somewhat unreliable. This particular error message is confusing, but it has nothing to do with whether your Universal Linking configuration is correct. What it actually means is Apple can't detect applinks: entitlements and 'proper' handling of passed-in link values in the version of your app that is currently live in the App Store. This is expected if you are just implementing Universal Links for the first time. You don't need to worry about this — a number of large and successful apps with working Universal Links implementations fail this step too.
I built a chrome extension. I don't want to host it (yet) in the chrome webstore. I want to self host it. I have packaged the .crx, and deployed it to my localhost. Here is the code I use to serve it:
app.get('/myext.crx', function(req, res){
var file = __dirname + '/public/myext.crx';
res.download(file);
});
Then I have an anchor tag that points to the file:
Install <strong>myExt for Chrome</strong>
When it downloads, it has the correct content-type header (per the instructions http://developer.chrome.com/extensions/hosting.html). Here is the info from the Network tab in Chrome Devtools when I click the anchor:
**Response Headers**
Connection:keep-alive
Content-Description:File Transfer
Content-disposition:attachment; filename=myext.crx
Content-type:application/x-chrome-extension
Date:Sat, 14 Dec 2013 07:09:46 GMT
Transfer-Encoding:chunked
X-Powered-By:Express
It all looks good, but Chrome still shows me the yellow banner error saying "Apps, extensions, and user scripts cannot be added from this website".
Am I missing a setting in the manifest? Can someone tell me what the issue is? Does it have anything to do with the fact that I am serving on localhost and the "homepage_url" and the "update_url" both point to my actual domain name?
Anyone, please.
UPDATE
It downloads the file, but gives me the aforementioned error. If I open Tools > Extensions and then drag the file from the bottom of Chrome onto the Extensions page, it won't install it. Nothing happens. HOWEVER, if I open a Finder window and drag it from the Finder window onto Tools > Extensions page, it installs fine.
Not sure if this info helps or not.
Chrome is starting to block extension installs that are not from the Chrome Web Store. If you don't want an extension to be fully published in the CWS, you can limit the audience with the publish to test accounts or accessible by URL only features.
I am trying to use System.Net.WebClient in a WinForms application to upload a file to an IIS6 server which has Windows Authentication as
it only 'Authentication' method.
WebClient myWebClient = new WebClient();
myWebClient.Credentials = new System.Net.NetworkCredential(#"boxname\peter", "mypassword");
byte[] responseArray = myWebClient.UploadFile("http://localhost/upload.aspx", fileName);
I get a 'The remote server returned an error: (401) Unauthorized', actually it is a 401.2
Both client and IIS are on the same Windows Server 2003 Dev machine.
When I try to open the page in Firefox and enter the same correct credentials as in the code, the page comes up.
However when using IE8, I get the same 401.2 error.
Tried Chrome and Opera and they both work.
I have 'Enable Integrated Windows Authentication' enabled in the IE Internet options.
The Security Event Log has a Failure Audit:
Logon Failure:
Reason: An error occurred during logon
User Name: peter
Domain: boxname
Logon Type: 3
Logon Process: ÈùÄ
Authentication Package: NTLM
Workstation Name: boxname
Status code: 0xC000006D
Substatus code: 0x0
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 127.0.0.1
Source Port: 1476
I used Process Monitor and Fiddler to investigate but to no avail.
Why would this work for 3rd party browsers but not with IE or System.Net.WebClient?
I have seen a similar issue, where the Integrated / NTLM security will only work if you are accessing the host by machine name or localhost. In fact, it is a [poorly] document feature in Windows that is designed to protect against "reflection attacks".
Basically, you need to create a registry key on the machine that is trying to access the server, and whitelist the domain you are trying to hit. Each host name / FQDN needs to be on it's own line - there are no wildcards and the name must match exactly. From the KB Article:
Click Start, click Run, type regedit, and then click OK.
In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Right-click MSV1_0, point to New, and then click Multi-String Value.
Type BackConnectionHostNames, and then press ENTER.
Right-click BackConnectionHostNames, and then click Modify.
In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
Exit Registry Editor, and then restart the computer.
http://support.microsoft.com/kb/956158/en-us
Have you tried ...
new NetworkCredential( "peter", "password", "boxname" );
You might also try ...
var credCache = new CredentialCache();
credCache.Add( new Uri ("http://localhost/upload.aspx"),
"Negotiate",
new NetworkCredential("peter", "password", "boxname"));
wc.Credentials = credCache;
Also, according to this it may be that IIS is configured wrong. Try replacing "Negotiate" with "Basic" in the above and checking your IIS config for the website. There's also a bunch of possible causes here.
Try going into IE's options and explicitly add the site to the Intranet Zone. Then re-run the program. You should also not run the program from an administrator login. This may trigger the Enhanced Security Configuration for Internet Explorer.
It could explain why you can hit the site with Firefox and Opera, but not with IE or WebClient.
Without knowing your IIS deployment, and assuming that you have the correct authorization rules for upload set in IIS (e.g. the right allow* ACL's on the right dirs you are trying to upload content to, etc), first thing I would try is to set UseDefaultCredentials to true instead of explicitly set Credential. (Maybe you think you are accessing the server with the Credentials you are setting but that's not the case? That would be possible if this works.)
This is a very common scenario, so I would focus on IIS authorization rules for the directory in which you are trying to upload the file, the actual ACL's on that directory. For ex. is your site impersonating or not? if it is, then you have to have actual ACL's on that dir, otherwise whatever account app pool is running on.