I work with Oracle SOA Suite and need to add one transport header Access-Control-Allow-Origin: *
In the configuration the server weblogic for get this:
this picture is of one service in IIS7, that he have the next configuration:
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Methods" value="OPTIONS,POST" />
<add name="Access-Control-Allow-Headers" value="Content-Type,SOAPAction,origin" />
</customHeaders>
</httpProtocol>
How I do this in weblogic server?
for default in the browser whit weblogic he show this:
You will have to set the property 'Access-Control-Allow-Origin' inside your webservice
This might help you :
https://techgrit.blogspot.com/2018/09/enable-cross-origin-resource-sharing.html
Related
Trying to move a legacy web application from IIS8 to an Azure web app. The app includes many ajax calls to WCF services that are built with no endpoint configuration, similar to the method described here: http://stevemichelotti.com/restful-wcf-services-with-no-svc-file-and-no-config/
As suggested in the article, System.Web.Routing is used to route requests to the correct service. For example, my global.asax includes routes like this:
RouteTable.Routes.Add(new ServiceRoute("svc/cmp/", new WebServiceHostFactory(), typeof(CompanyService)));
RouteTable.Routes.Add(new ServiceRoute("svc/cont/", new WebServiceHostFactory(), typeof(ContactsService)));
So, a request for http://example.com/svc/cmp/GetCompany?id=1234 would be routed to CompanyService for handling.
These calls all work fine when running on IIS, but return 404 not found errors on Azure web app.
I tried adding handlers to web.config, like this:
<system.webServer>
<handlers>
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
Also tried adding a handler mapping in the Azure app settings to have all extensions (*) handled by %windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll.
No luck in either case.
This was resolved by deleting the Azure web app and recreating it. It was originally created with the WordPress template with a virtual directory/application hosting the .net portion of the site.
Apparently, not all routing modules are loaded with the WordPress template so the WCF services were not routed correctly. After it was recreated with the web app template all the services worked just fine.
Update
This issue resurfaced after re-installing WordPress. Now that I have a better understanding of what's going on I thought I should update in case anyone has a similar issue.
WordPress is installed in web site root and the WCF services are in a child app. Turns out that WordPress created a rewrite rule in the web.config of the root which broke my WCF services. The rewrite rule looks like this:
<rewrite>
<rules>
<rule name="Wordpress: https://example.com" patternSyntax="Wildcard">
<match url="*" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="index.php" />
</rule>
</rules>
</rewrite>
This rule has to do with enabling pretty permalinks and says "if the URL does not correspond to a file or a folder on the file system, it will rewrite the URL to the index.php file".
Well, my WCF services have URLs that don't correspond to a file or folder, so they were all broken. The situation was resolved by clearing rewrite rules in the web.config in the child app:
<rewrite>
<rules>
<clear />
</rules>
</rewrite>
Lesson learned.
While developing a ASP.NET MVC4 web application with VS2010, using the Mvc.JQuery.Datatables Nuget,
I found that the EmbeddedResourceVirtualPathProvider NuGet that is referenced, worked beautifully
on my dev box, but failed miserably on my production box.
The production box is Windows 2003, with IIS6 and .NET 4.0 installed.
I searched many things on SO, and Googling, but after implementing the suggested workarounds,
it still fails:
Here's what I've done.
Implement AppInitialize as suggested by https://stackoverflow.com/a/5178993
Implemented Wildcard mapping for ASP.NET as suggested by http://haacked.com/archive/2008/11/26/asp.net-mvc-on-iis-6-walkthrough.aspx
Implemented IgnoreRoute for static files as suggested by https://stackoverflow.com/a/3144841
but it still doesn't serve all of the files. I'm getting the embedded partial views, but not
the embedded css, js, and jpg files.
My web.config has an entry for the StaticFileHandler as follows:
<system.webServer>
<handlers>
<add path="*.css" verb="GET" name="Static css" type="System.Web.StaticFileHandler" />
<add path="*.js" verb="GET" name="Static js" type="System.Web.StaticFileHandler" />
<add path="*.jpg" verb="GET" name="Static jpg" type="System.Web.StaticFileHandler" />
<add path="*.gif" verb="GET" name="Static gif" type="System.Web.StaticFileHandler" />
</handlers>
</system.WebServer>
I appear to be missing something critical. Any Suggestions?
When using IIS6, all of the items listed in #1-3 are required, but additionally, you need to
recognize that IIS6 defines its handlers as httpHandlers in the system.web section,
whereas IIS7 calls them handlers and they are in the system.webServer section of the config file.
Therefore, you need to add the following to make it work in IIS6
<system.web>
....
<httpHandlers>
<add path="*.css" verb="GET" type="System.Web.StaticFileHandler" />
<add path="*.js" verb="GET" type="System.Web.StaticFileHandler" />
<add path="*.jpg" verb="GET" type="System.Web.StaticFileHandler" />
<add path="*.gif" verb="GET" type="System.Web.StaticFileHandler" />
</httpHandlers>
</system.web>
I'm attempting to gzip a JSON response from an ASMX web service to be consumed on the client-side by jQuery.
My web.config already has httpCompression set like so: (I'm using IIS 7)
<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files"
staticCompressionDisableCpuUsage="90" staticCompressionEnableCpuUsage="60"
dynamicCompressionDisableCpuUsage="80" dynamicCompressionEnableCpuUsage="50">
<dynamicTypes>
<add mimeType="application/javascript" enabled="true"/>
<add mimeType="application/x-javascript" enabled="true"/>
<add mimeType="text/css" enabled="true"/>
<add mimeType="video/x-flv" enabled="true"/>
<add mimeType="application/x-shockwave-flash" enabled="true"/>
<add mimeType="text/javascript" enabled="true"/>
<add mimeType="text/*" enabled="true"/>
<add mimeType="application/json; charset=utf-8" enabled="true"/>
</dynamicTypes>
<staticTypes>
<add mimeType="application/javascript" enabled="true"/>
<add mimeType="application/x-javascript" enabled="true"/>
<add mimeType="text/css" enabled="true"/>
<add mimeType="video/x-flv" enabled="true"/>
<add mimeType="application/x-shockwave-flash" enabled="true"/>
<add mimeType="text/javascript" enabled="true"/>
<add mimeType="text/*" enabled="true"/>
</staticTypes>
<scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll"/>
</httpCompression>
<urlCompression doDynamicCompression="true" doStaticCompression="true"/>
Through fiddler I can see that normal aspx and other compressions work fine. However, the jQuery ajax request and response work as they should, only nothing gets compressed.
What am I missing?
You can change httpCompression only in applicationHost.config.
See this link
Like you, I tried changing it in web.config first, but it didn't work. It worked only when I added the following lines to C:\Windows\System32\inetsrv\config\applicationHost.config:
<dynamicTypes>
...
<add mimeType="application/json" enabled="true" />
<add mimeType="application/json; charset=utf-8" enabled="true" />
...
</dynamicTypes>
DO USE NOTEPAD to edit applicationHost.config. I've wasted several hours before understood that my changes made in notepad++ (as well as in Visual Studio 2010 editor!!) aren't applied by IIS.
Alternative way to add additional mimeType into dynamicTypes/staticTypes collection is to use appcmd. "C:\Windows\System32\Inetsrv\Appcmd.exe" set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='application/javascript',enabled='True']" /commit:apphost
And again: after these changes made - you'll see them only in notepad. Notepad++ (as well as Visual Studio 2010 editor!!) maintains some kind of f*ing alternate reality/storage for applicationHost.config. It shows you his own version of the file (different from the one you see in notepad) even after the file edited in notepad and reopened in np++/VS.
Eric P's answer is mostly correct... you need to EXACTLY match the Content-Type header sent by IIS in its HTTP Response Headers. For some reason our IIS7 server was responding with:
Content-Type: application/json; q=0.5
I had never ever observed a quality factor in a server response before. How bizarre.
When we added this to the dynamicTypes in the .config file everything started working:
<dynamicTypes>
...
<add mimeType="application/json" enabled="true" />
<add mimeType="application/json; q=0.5" enabled="true" />
<add mimeType="application/json; charset=utf-8" enabled="true" />
<add mimeType="application/json; q=0.5; charset=utf-8" enabled="true" />
...
</dynamicTypes>
Changes in web.config don't work because of the following line in applicationHost.config:
<section name="httpCompression" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
If you replace it by:
<section name="httpCompression" overrideModeDefault="Allow" />
the changes are possible locally.
I think this is more convenient as you are able to configure every service differently and you don't have to edit your applicationHost.config if you must add a new MIME type.
Here is an example how to activate compression in web.config on a single ASMX service located in the service subfolder:
<location path="service/MySpecificWebService.asmx">
<system.webServer>
<httpCompression>
<dynamicTypes>
<add mimeType="application/json" enabled="true" />
<add mimeType="application/json; charset=utf-8" enabled="true" />
</dynamicTypes>
</httpCompression>
<urlCompression doDynamicCompression="true" />
</system.webServer>
</location>
Concerning the actual editing of applicationHost.config, I suspect that it is not a true file in the file system. If you copy that file on your desktop, you will be able to edit it with any text editor, then copy it back to its original folder.
http://forums.iis.net/t/1160210.aspx?missing+applicationhost+config
The config file is supposed to be %windir%\system32\inetsrv\config\applicationhost.config.
(Note that if your application (which is searching for applicationhost.config) is a 32bit app (for example, if you're using a 32bit CMD.EXE), then you won't be able to see the configuration file due to Windows SYSWOW32 redirection)
A bit of explanation regarding the missing applicationhost.config to change overrideModeDefault attribute to Allow. It's due to SYSWOW32 redirection.
Also you may not see the configuration files until you
Open the folder by pasting "%windir%\system32\inetsrv\config\" exactly in the File Explorer location bar, and not your text editor
Right-click and edit the file directly in that folder.
This is because for some reason some 64bit editors still use a faulty file-chooser dialog somehow.
I've got an existing web application, that is installed on several machines. script clients and .net clients consume ".asmx" services through one machine, that routes all calls to other machines.
Client ----> |Website \ Virtual directory(HttpHandler)| ----> |Other server \ real .asmx|
I added a new .svc service that does the same functionality, and added a handler for it (directory's config):
<system.webServer>
<handlers>
<add name="MY_ASMX" verb="*" path="*.asmx" type="MY.AO.HttpProxy, Astea.AO.HttpProxy" resourceType="Unspecified" preCondition="integratedMode" />
<add name="MY_ASPX" verb="*" path="*.aspx" type="MY.AO.HttpProxy, Astea.AO.HttpProxy" resourceType="Unspecified" preCondition="integratedMode" />
<add name="MY_WSDL" verb="*" path="*.wsdl" type="MY.AO.HttpProxy, Astea.AO.HttpProxy" resourceType="Unspecified" preCondition="integratedMode" />
<add name="MY_SVC" verb="*" path="*.svc" type="MY.AO.HttpProxy, Astea.AO.HttpProxy" resourceType="Unspecified" preCondition="integratedMode" />
while asmx request are routed fine, my new .svc on the end server does not get called, and even the Httphandler is skipped. if i call the .svc directly on the other machine it works.
the error i get is:
WebHost failed to process a request.
Sender Information: System.ServiceModel.Activation.HostedHttpRequestAsyncResult/26458746
Exception: System.Web.HttpException (0x80004005): The service '/Mysite/MyDirectory/settings.svc' does not exist. ---> System.ServiceModel.EndpointNotFoundException: The service '/Mysite/MyDirectory/settings.svc' does not exist.
I already tried the folowing
add "buildProviders" to compilation section that removes .svc
Click on MimeTypes and enter “.svc” and “application/octet-stream” and save
add a handler :
nothing helps, http handler is not being called
p.s. Im working with AppPool .net 4.0 Integrated
.svc extensions are considered by default to be WCF services, and handlers/modules are already present for them. You can remove the existing handlers/modules by putting a element before your <add> element:
<remove name="svc-ISAPI-4.0_32bit" />
(or, if on win64:)
<remove name="svc-ISAPI-4.0_64bit" />
And, in the <modules> element:
<remove name="ServiceModel-4.0" />
I've found it. Adding:
<compilation debug="true" >
<buildProviders>
<remove extension=".svc"/>
</buildProviders>
</compilation>
caused an error, that got me to back off, at the first time:
"~/ServiceManagement.svc" demanded that the buildProvider for ".svc" will be on
"~/ServiceManagement.svc" is automatiacally created in the machine root config when you install MS AppFabric. Since I'm using that folder only for redirection, I don't need Appfabric there, so I removed it:
<system.serviceModel>
<serviceHostingEnvironment>
<serviceActivations>
<remove relativeAddress="~/ServiceManagement.svc"/>
</serviceActivations>
</serviceHostingEnvironment>
I have created a WCF service that uses windows authentication and would like to set it so it can only be accessed if the user is in a Windows group. I Currently use the following attribute in code to make this happen
[PrincipalPermission(SecurityAction.Demand, Role = "Domain\MyGroup")]
Problem with this is I have to do it on each method and compile if I want to change the group. Is there a way so I can set the group that has access in the config file and for the services as an whole?
I have tried the following in my config file but this does not appear to work
<security>
<authentication>
<windowsAuthentication authPersistSingleRequest="true" enabled="true"/>
</authentication>
<authorization>
<add accessType="Allow" roles="Domain\MyGroup" />
</authorization>
</security>
Ok I figured it out. I have the config file set like the following
<security>
<authentication>
<windowsAuthentication enabled="true" />
</authentication>
<authorization>
<remove users="*" roles="" verbs="" />
<remove users="?" roles="" verbs="" />
<add accessType="Deny" users="?" />
<add accessType="Allow" roles="Domain\MyGroup" />
</authorization>
</security>
Also had to set
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
And on my class that implements the WCF contract
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
I guess this means Im using ASP authentication rather than WCF but I works for me
The PrincipalPermission attribute is from the .NET code access security functionality and isn't related to WCF. A more flexible way to do this if the service is hosted in IIS is shown in this MSDN post. WCF also supports different custom authentication mechanisms as described here.