Recently I launched a WordPress site (Note: inmotion linux server) with Gravity Forms (GFrom). The site uses a GFrom as a job application and has an input for users to upload their resume. I have tested it, it works and I can login to the WP Dashboard View and Download all the entries ( in all browsers ) just fine.
After turning things over to the client, they came back to us saying they are unable to view or download the uploaded resumes from the Gravity Forms "Entries" section (Note: the client is able to access both the front and backend of the site, issue seems to only be related to the viewing and or downloading the resumes). They get a 404 error. Now the weird thing is, the 404 error they are getting was part of their old site on a completely different server (Note: Non WP on a godaddy windows server). They have tried clearing their browser cache and no success. Does anyone know what can cause this?
Related
I deployed a react project of mine with Netlify. It was successfully deployed and I can access the site. However, after a few weeks of checking out the site again, it says that
This site can’t be reached
Check if there is a typo on my site
The weird thing is it only shows that the site can't be reached if I am connected to my WiFi, tried it both on my laptop and my phone, same results show. However, if I use mobile data, it will load up fine.
I am trying the GMail API Node.js quickstart on Windows 10.
I do get the expected
.
However when I visit the url I get
for http://localhost/?code=4/xxxxxxxxxxxxxxxxxx&scope=https://www.googleapis.com/auth/gmail.radonly
I get this error after going through 'This app isn't verified'/'Advanced > Go to {Project Name} (unsafe)'. message.
No Proxy active and also tried with AntiVirus disabled.
Any ideas what the problem could be?
Thanks.
The issue you are having is that you are runing a Authorization credentials for a desktop application. Google made a change recently which deprecated the oob redirect. This means that now you need to use localhost or 127.0.0.1 as a redirect endpoint for installed applications.
Resulting them in returning the authorization code back to the browser showing site can not be reached because your not running a web app you are running an installed application.
If you check the url the authorization code you are looking for to add to your code can be found there. just take that code and submit it where it asks for it.
Enter the code from that page here:
There is currently no other option and no way to fix this unless you want to start up a web server in node. basicly its working as intended and Google is in the process of updating all the Javascript samples to reflect that.
The Application
In short, the application surfaces data from a backend onto a web page. The client application is a Single Page Application made using AngularJS. It calls an ASP.NET Web API service located on a different domain to retrieve the data. I utilize BreezeJS on both the client application and the web service to manage this data. The client is hosted on a SharePoint Online site, and the service is hosted on IIS7.
The Error
I encounter an "Access is Denied" error when AngularJS attempts to make an XMLHttpRequest.open() call targeting this web service. However, though this seems like a simple CORS issue, it has some peculiarities which have me stumped:
Foremost, this error only occurs when using Internet Explorer 11 (or a previous version). When the application is viewed in Chrome or Firefox, it can connect and retrieve data from the service.
The web service is configured to accept the calling origin.
No network traffic is detected either by the native IE development tools or by Fiddler.
Specifically, the line: xhr.open(method, url, true); of the angular.js file throws this error.
Does anyone have any insight as to why this error occurs?
Also, if more specific details are needed I certainly can provide them. I'm not even sure where the issue might be coming from and I don't want to dump tons of irrelevant lines of code.
I think that this is due to using "localHost", i.e when attempting to access a resource in the "Local intranet" zone from an origin in the "Internet" zone.
See: Access denied in IE 10 and 11 when ajax target is localhost
This is not just a localhost issue as previously suggested. I have a production AngularJS application that is trying to POST to a public Web API 2 on a different domain. IE11, Chrome, and Firefox work without a hitch when the site is accessed externally. When accessing from a subnet that can talk directly to those servers, I get Access Denied and IE doesn't even send the request (Chrome and Firefox work flawlessly, of course. One workaround (I refuse to call this a fix) is to add the site as a Trusted Site in IE11. Even when the security settings for Internet mirror the settings for Trusted Site, I get access denied. I have to add the site on each internal IE system to gain access.
OK, this used to work, but it appears to have stopped working on January 1st.
We have a .NET page that is displaying some data to our internal mobile users. This page is set up with Anonymous Authentication in IIS7. (Windows Server 2008 R2 is the OS of the web server.) When accessing via our intranet, the page displays fine. When attempting to access via our Blackberries, we get the following error message:
"Error: Page cannot be displayed. Please contact your service provider for more details. (1)"
Is this an IIS error, an AT&T issue, or a Blackberry issue? My Director is on my case about it, and I'm not experienced enough in IIS to know of anything else that would cause this functionality...
You should check with your network ops team. I'm guessing that the blackberries are accessing the server from the external intranet (that's just a guess though) ... so have them double check that the domain/ip is accessible externally. That could be why you can access it from in the network.
Or if your blackberries are configured to access the network via VPN, I would double check that connectivity.
Forgot to post the resolution to this.
It turned out to be a Blackberry issue. With the latest OS, RIM combined the internal and external browsers into one browser. Said browser attempts to determine if a given site is an intranet or internet site. Even though the BES (sp?) was set up correctly, our service was still spotty. Some people could enter our intranet homepage address and get the intranet; others got the web squatter site on the internet. Since the page we were trying to access was nested fairly deeply in the directory structure, the web squatters didn't have a page with that name in their site. That's why we were getting the error shown above.
Our resolution - we created a different BES alias to point to our intranet, and rolled that out to all applicable users. Utilizing this, the browser didn't have to determine if we wanted our intranet site or the page on the internet; it correctly displayed the intranet page.
We currently have a Silverlight application which is hosted in a SharePoint 2010 page. The Silverlight app makes web service calls to a another server on our domain, which has a clientaccesspolicy file in place. We are experiencing cross-domain issues in our production environment.
Users in the farm admin group can use the Silverlight application without any issues. However, all other users recieve the generic cross domain exception when they try to use this app. We have attached Fiddler to the process and noticed that the farm admins are served the clientaccesspolicy file, but that non-admin users are not. In fact, Fiddler does not ever show an attempt to load this file for non-admins.
This only happens in our production environment, which leads me to believe there is a web config or permission setting causing the issue. Unfortunately, I cannot find anything that backs this up.
Has anyone else run into this issue or know if such a setting exists?
See comments above. I had to change the URL to use the full machine name i.e. from webserver/service.svc to webserver.domain.com/service.svc. It solved the problem but doesn't answer the question about why the farm admins could access it. vorrtex's response is the best possible explanation I have seen so far.