I created a component in Flex which auto completes a couple of text inputs when users are typing an entry. When running the application from Flex, everything works fine. However, after I have compiled the application and load it, the auto complete does not work. Here is some background information.
Created in Adobe Flash Builder 4.5.
Web Application is running on an internal network.
The service which the auto complete uses is an external service.
The internal server which hosts the web application can load the URL of the external service just fine.
I am not sure if it this is a permissions issue or what. Any insight would be appreciated.
I had similar problems with receiving data from a web service. If the crossdomain file is not where it is supposed to be (webservice.domain.com/crossdomain.xml), you will receive a 404 error. So it does not sound like that is your issue. If your crossdomain file does not contain the right tags, however, it won't throw an HTTP error, but it still won't work either.
It won't work properly by default if you are going from an HTTP server (where your application resides) to an HTTPS server (where your service is). This is typically bad security practice, but if you decide that it is OK, you can use the secure="false" for the allow-access-from tag.
Also, you may need to include both the allow-access-from tag and the allow-http-request-headers-from tag to get the data you are looking for.
Here is the crossdomain policy file specification by Adobe and it is a good resource in figuring out what attributes are required for each tag: http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html.
Good luck!
Related
I am supporting ASP.NET application running on 3 web servers and have F5 system as firewall and load balance. Actually I don't have experience at all in F5 system but the following issue seems to be related to it
The issue happened after we applied F5 load balancing. Simply it cause JavaScript in the web page to fail sometimes. After refresh the web page it will work fine
To trace the issue I compared the response that fail and the one that success after refresh. The difference was the failed one contains html tag that is not added by our application apm_do_not_touch with a script tag inside it
It seems that happen when the F5 switch between one server to another one as the issue solved when we redirect all the traffic to only one server
Any advice, what is the possible cause and how we can solve it?
APM is F5's Access Policy Manager module and is used for VPN, Web Portals, and federated authentication. The apm_do_not_touch tag is part of this product and is used when you want to prevent the APM module from rewriting portions of HTML such as external links.
If you're not accessing the application through a web portal, this should not be applied and you'll need to work with whomever setup the access policy to resolve as the APM policy is being applied to your application possibly erroneously.
Here is more information on the apm_do_not_touch tag. Depending on your version, there was a known issue for #cc_on in F5 BIG-IP version 11.1 who's workaround was to prevent the APM module from rewriting that command. The same workaround may pose a solution for you. Either way, there are additional complexities to your client traffic flow that you will need to engage your network team/BIG-IP administrators with to ensure your application and their policies don't clash.
It could be as simple as removing the APM policy from your application's pathway but your admins will be able to identify if it's required for external access or reverse proxy requirements.
I've developed a new WEB API 2 that works great locally, however when I upload the same code to my production server (Arvixe in this case) all I get is a 404 when I call it. I've spent HOURS searching the web, reading forums, etc.. and have been able to find no resolution, so I'm asking here as my last effort.
I'm currently only testing with the default project that gets created when you do New Project > ASP.NET Web API 2 Empty Project in Visual Studio. This creates an empty project with a single ValuesController. You should be able the JSON response by called /api/values, but this doesn't even work.
I'm using Fiddler to test the API locally and on the web server.
http://localhost:1993/api/values <--- works great
but
http://api.mydomain.com/api/values <--- returns 404
Note: I created a subdomain "api" in this case, but everything for the code for the API is unchanged from when it was created.
Why in the world does this work locally but not on the production web server?
That the server returns 404 (Not Found) may indicate a lot of things. However you can check using the following step:
Add a simple text document like readme.txt to your a folder sub-domain http://api.mydomain.com, and try to get access to that. If you can't access to that file, it means that the subdomain is not configured properly.
Publish the webservice using the "Publish" functionality, so that all DLLs will be copied.
After that,try to reach the Web ApI again.
Hope that help.
"Note: I created a subdomain 'api' in this case, but everything for the code for the API is unchanged from when it was created."
Above comment of your's is suspicious, you should publish your WEB API application in the root directory. Like if http://example.com is pointing to "MyExample" folder, then application should be published on "MyExample" folder.
After that you will be able access your api with http://example.com/api/{controller}/{action}
Just a simple suggestion which I'm sure you have already considered, but have you opened the http port 80 on the server's firewall?
Also stick a plain old html file in the root of your project and see if the server serves it up.
in your case, since you create a subdomain of 'api', you should try
http://api.mydomain.com/api/api/values
note that if you're using database for the function, you should change the connectionString in your web config
Please verify the .net framework on you hosted domain that may be old one.
Web api 2 is supposed on 4.5 framework.
One reason for web api 2 method working OK on local machine but not on production server is that the method you are calling is working on local machine but not on remote server. In such a case you will receive message 404 or 500, and you would be lost why this routing is failing.
Why a method would fail on remote server, well there may be many reasons. For me, I was querying database in my method and my connectionString was not set for remote server.
One way of resolving it would be to put some very simple code in that particular method and test that routing is working. Then check your original code for errors reasons.
OK, co I have searched and tried what I think is everything. Basically I have an app I have built in Sencha Architect that uses a JSON proxy to call a Get method in my Web API. Running local host, not a problem, deploy to live, not a problem. Run localhost against live web api.. PROBLEM! :)
So, have spent the last couple of hours reading up on CORS and implementing Access Allow Origin in response header, even allowing "OPTIONS" in response header as part of the "pre-flight" check before trying to make the call and still no go. I have set request headers just in case in my call, but convinced this is not the actual issue. I get a 405 method not allowed, no matter what I do.
The crazy thing is, I just wanted to bundle this up as a native app and see if it worked... How does anyone else make a call to a public service using ASP.Net and IIS7.5 +?
Move your sencha app folder in asp.net project folder and run sencha app using IIS server
I'm having the classic (dare I say typical?) error on the ASP.NET production server, which tells me that I can't view errors. Below the error displayed below, are things I've already tried.
In IIS Manager (6.0), the application is located under one of the web sites in "Web Sites". It is indeed a web application, as opposed to a virtual directory (it has that gear icon).
When trying to view the error from the localhost (i.e. the server itself), it doesn't find the application on its path, even though the root web site works just fine from localhost. It is clearly not a firewall issue because first of all, the firewall is turned off, and second because the root web site works fine from localhost. Heck, I even tried connecting through telnet and that worked fine and dandy too, so it is most certainly and very clearly not a firewall issue.
Basically, I just need to view the error at all. I won't have to fix this problem if I can just see the error and fix it, because obviously there is something wrong in the code itself... I just don't know what, because IIS/.NET won't tell me.
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Details: To enable the details of this specific error message to be viewable on remote machines, please create a tag within a "web.config" configuration file located in the root directory of the current web application. This tag should then have its "mode" attribute set to "Off".
So what I've already tried is what the error message itself suggests by setting the customErrors thing to "Off". In fact, it always was on "Off" so I didn't have to change anything. I've made sure that the web.config XML is valid.
Another common reason for this error is that the .NET run-time is set to version 1.1, not 2.0. I've also made sure that this is correctly configured to 2.0.
I'm running it in an independent application pool, meaning that there are no other applications at all, much less 1.1 applications, on the same application pool.
I've made sure that EVERYONE can do ANYTHING to the files and directories in the application itself. I understand the security ramifications here, I'm just trying to get it working at all, and then I'll constrain the access rights afterward, one step at a time. But in any case, everyone can read those files.
Any help deeply appreciated. Thank you in advance.
The error is a .NET framework error so it finds the app, but there is a configuration error. What you could do is add some event logging code in APplication_Error handler in global.asax to trap these errors, or turn on health monitoring (<healthMonitoring enabled="true" />), which by default will log ASP.NET framework errors to the event log.
HTH.
Never got this working until I changed the application from a "sub-application" (I don't know the proper terminology) to an independent website with its own hostname. ASP.NET works in mysterious ways.
I have a need to integrate a third-party Java applet into a custom web part I wrote for SharePoint 2007. The web part simply loads a user control I created that contains the bulk of the functionality, and that's where the applet will go. I added it to my user control project and it works fine outside of my SharePoint environment.
I installed the updated web part onto my MOSS 2007 development site and the part's page loads fine. The applet is triggered by clicking a link button on the page, which runs some client-side JavaScript to start it. The problem is nothing seems to happen when I click the link. No error messages appear, and the stuff the applet is supposed to do never occurs (it's for doing file transfers via FTP). I have the .jar file as an embedded resource in my user control DLL, which is deployed to the bin folder, and SharePoint fully trusts this DLL.
I used Firebug to step through the initialization code and I saw an HTTP GET that failed with a message about not being authorized, but it didn't give any details and I'm not positive it was related to the applet.
Is there anything special I need to do to make the applet work? Or am I going about this the wrong way?
EDIT: The problem turned out to be the .jar file for the applet couldn't be found. SharePoint is clearly doing something different here, and I need to find out what. Can Java applets be used within a SharePoint site? This question suggests they can, but in that case a Page Viewer web part was used, which isn't going to really work for me.
An applet in HTML is handled by applet/object tag. Your webpart should just render the OBJECT/applet tag and its attributes relevant to the applet (code, height, width) or you can let the JavaScript do it all and your webpart can provide the marker div where the applet needs to be rendered. That's about it and Sharepoint does not have to have any more knowledge about the applet since it is all taken care of the browser. The archive parameter points to the jar that can be located on your server than should be browsable. Instead of bundling it as a resource in the DLL , host it on the server just outside of the Sharepoint website. You might have to create a virtual directory in a different website for the same. This simplifies the deployment model.
It is possible the applet make a HTTP call back to the SharePoint site and it does not pass any credentials