I am trying to get data from my server, used RemoteObject to accomplish it.
When I run the application on my localhost it works great but when iam using it on my server i get a Channel.Security.Error(Security Error accessing URL).
On the server side logs there is a mention about cross domain .
77.127.194.4 - - [23/Oct/2008 21:15:11] "GET /crossdomain.xml HTTP/1.1" 501
Any one encountered the same problem ? any idea ?
Have you tried to add to your crossdomain.xml (where your fetching the stuff from) this:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.YOUR_FRAME_WORK_CROSSDOMAIN_POLICY.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*.YOUR_SITE_GOES_HERE.com" secure="false" />
<allow-access-from domain="*.YOUR_SITE_GOES_HERE.com" secure="false" />
</cross-domain-policy>
The stuff in capslock you'll probably have to change to fit your framework. For example i copied that from the one i use with macromedia flash. Instead of "www.YOUR_FRAME_WORK_CROSSDOMAIN_POLICY.com/..." i normaly have "www.macromedia.com/xml/dtds/...
I'm not sure but try to investigate that, it's probably your problem. For cross-domain, you normaly need to add to the server side, where your fecthing stuff from, permission for other sites to get it.
I have found the solution. You are right about crossdomain.xml file, but unfortunately, the Python SimpleXMLRPCServer library does not support the GET method by default, so we need to implement this.
from SimpleXMLRPCServer import SimpleXMLRPCRequestHandler
class ExtendedXMLRPCRequestHandler(SimpleXMLRPCRequestHandler):
def do_GET(self):
#only allow a request for the crossdomain file
if self.path != '/crossdomain.xml':
self.send_response(403)
self.log_request(403)
return
#open the crossdomain file and read its contents
response = open('crossdomain.xml', 'r').read()
#write the data to the socket along with valid HTTP headers
self.send_response(200)
self.send_header("Content-type", "text/xml")
self.send_header("Content-length", str(len(response)))
self.end_headers()
self.wfile.write(response)
self.log_request(200)
Related
As the title says. I have some EJBs in an EAR and I have a client jar providing remote methods to a JSF app also sitting in liberty (different server/machine). The client jar tries to access the remote EJBs via lookup.
This is breaking my heart for two days now. As the title says...
I am aware of other stackoverflow questions from the past and I am aware of the following resources:
https://www.ibm.com/docs/en/was-liberty/core?topic=liberty-using-enterprise-javabeans-remote-interfaces
https://github.com/OpenLiberty/open-liberty/blob/release/dev/com.ibm.ws.ejbcontainer.remote_fat/test-applications/RemoteClientWeb.war/src/com/ibm/ws/ejbcontainer/remote/client/web/RemoteTxAttrServlet.java
I have tried every combination provided in the above but no joy.
I use (wlp-javaee8.21.0.0.8) with javaee8 feature enabled, this enables everything else I need e.g. ejb-3.2, ejbRemote-3.2, jndi-1.0 and a few others)
I have an EAR my-ear that contains a module my-module-1.0.4-SNAPSHOT.jar which contains my beans. I am using gradle/liberty plugin and IntelliJ.
I am using tests from within IntelliJ in the client jar module to try to access the remote beans.
My myEAR deploys fine and starts up fine and the app shows running in admincenter. In messages.log I see my EJB bindings. Just picking one example.
[16/08/21 10:58:42:384 IST] 00000022
com.ibm.ws.ejbcontainer.osgi.internal.NameSpaceBinderImpl I
CNTR0167I: The server is binding the
my.org.functiona.ejb.advance.MyAdvance interface of the MyAdvanceBean
enterprise bean in the my-module-1.0.4-SNAPSHOT.jar module of the
my-ear application. The binding location is:
ejb/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
[16/08/21 10:58:42:385 IST] 00000022
com.ibm.ws.ejbcontainer.osgi.internal.NameSpaceBinderImpl I
CNTR0167I: The server is binding the
my.org.functiona.ejb.advance.MyAdvance interface of the MyAdvanceBean
enterprise bean in the my-module-1.0.4-SNAPSHOT.jar module of the
my-ear application. The binding location is:
my.org.functiona.ejb.advance.MyAdvance [16/08/21 10:58:42:385 IST]
00000022 com.ibm.ws.ejbcontainer.runtime.AbstractEJBRuntime
I CNTR0167I: The server is binding the
my.org.functiona.ejb.advance.MyAdvance interface of the MyAdvanceBean
enterprise bean in the my-module-1.0.4-SNAPSHOT.jar module of the
my-ear application. The binding location is:
java:global/my-ws-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean!my.org.functiona.ejb.advance.MyAdvance
This is my corresponding interface:
package my.org.functiona.ejb.advance;
import javax.ejb.Remote;
#Remote
public interface MyAdvance {
This is my corresponding implementation:
package my.org.functiona.ejb.advance;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
#Stateless(mappedName = "MyAdvance")
#TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public class MyAdvanceBean implements MyAdvance {
Like I said, its breaking my heart. I tried every combination of provided in the (patchy) documentation and other sources. The most progress I made was by accessing "corbaname::localhost:2809/NameService" through a default InitialContext().lookup. So at least I was able to confirm I can gwet through to the NameService. But any subsequent bean lookup using that context with any combination of the names provided in messages.log or in the code snippets from documentation all fail with the exception below.
javax.naming.NameNotFoundException [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
Same for InitialContext() lookups where I prefix the names with "corbaname::localhost:2809/NameService#".
I tried
ejb/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
ejb/global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
ejb/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvance#my.org.functiona.ejb.advance.MyAdvance
ejb/global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvance#my.org.functiona.ejb.advance.MyAdvance
java:global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvance#my.org.functiona.ejb.advance.MyAdvance
java:global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
my.org.functiona.ejb.advance.MyAdvance
and probably a few others
I replaced the # sign with an exclamation mark in all of the above. And went through it again.
I tried corbaloc:: and corbaloc:iiop: for context. Nothing.
I am no web dev expert but this feels very try and error and I dont feel it should be like that. I understand in websphere proper I could identify the names in the admin console but then I'm not even certain websphere proper and liberty behave the same way.
Sine accessing EJBs from remote seems bread & butter stuff I assume I am overlooking something basic and silly due to my inexperience.
Any pointers anyone? Thank you so much for your time reading this.
Carsten
Edit: server.xml
<server description="disbCoreServer">
<featureManager>
<feature>javaee-8.0</feature>
<feature>adminCenter-1.0</feature>
<feature>websocket-1.1</feature>
</featureManager>
<quickStartSecurity userName="admin" userPassword="carsten" />
<!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" -->
<httpEndpoint id="defaultHttpEndpoint"
host="${hostname}"
httpPort="${default.http.port}"
httpsPort="${default.https.port}">
<accessLogging filepath="${com.ibm.ws.logging.log.directory}/accessLog.log" logFormat='%h %i %u %t "%r" %s %b %{R}W' />
<tcpOptions soReuseAddr="true" />
</httpEndpoint>
<include location="appConfXML/disb_core_jndi.xml"/>
<include location="appConfXML/disb_core_jdbc.xml"/>
<include location="appConfXML/disb_core_jms.xml"/>
<include location="appConfXML/disb_core_mail.xml"/>
</server>
The example provided through the FAT test (remoteLookup) works just fine. I just didnt have all my ducks in a row.
https://github.com/OpenLiberty/open-liberty/blob/release/dev/com.ibm.ws.ejbcontainer.remote_fat/test-applications/RemoteClientWeb.war/src/com/ibm/ws/ejbcontainer/remote/client/web/RemoteTxAttrServlet.java
My scenario is serverA hosting EJBs and serverB running the remote client calling serverA's EJBs.
Steps on serverB are:
Get (local) InitialContext with no properties: InitialContext initialContext = new InitialContext();
With the above lookup the remote Context: Context remoteContext = (Context) initialContext.lookup("corbaname::remotehost:remotePort/NameService");
With the remoteContext lookup the EJB remote interfaces and 'narrow' and cast them to appropriate type
String lookupName = "ejb/global" + "/" + "MyAppName" + "/" + "MyModuleName" + "/" + jndiName;
Object remoteObj = remoteContext.lookup(lookupName);
return interfaceClass.cast(PortableRemoteObject.narrow(remoteObj, interfaceClass));
Where
"MyAppName" is my apps name, the name of the EAR in my case (without .jar)
"MyModuleName" is the name of the EJB module within my EAR (without .jar)
and jndiName is the bean name / fully qualified interface name separated by exclamation mark e.g. "MyBean!myorg.ejb.interfaces.MyBeanIfc"
Call the interfaces to remotely execute serverA EJB code
Note: When running serverA and serverB on the same machine (e.g. localhost) ensure they are not operating on the same port for NameService.
Thanks to everyone who tried to help!
I'm trying to connect to Bloomberg through the FIX protocol (4.4) using QuickFIX/n.
Bloomberg requires to use the TLS 1.2 protocol. I have installed the PFX certificate following the instructions.
My current FIX config file looks as follows:
[DEFAULT]
ConnectionType=initiator
ReconnectInterval=2
FileStorePath=store
FileLogPath=fixlog
StartTime=06:00:00
StartDay=monday
EndTime=22:00:00
EndDay=friday
SocketConnectHost=xxx.xx.xxx.xx
SocketConnectPort=8228
# standard config elements
[SESSION]
BeginString=FIX.4.4
SenderCompID=MY_COMP_ID
TargetCompID=BBG_COMP_ID
HeartBtInt=60
ValidateFieldsOutOfOrder=N
UseDataDictionary=Y
DataDictionary=FIX_BBG.xml
CheckLatency=N
[SSL]
SSLEnable=Y
SSLProtocols=Tls12
SSLValidateCertificates=Y
SSLCheckCertificateRevocation=N
SSLCertificate=C:\Services\FixEngineService\cert\pkcs12\cert.pfx
SSLCertificatePassword=xxxxxxxxxxxx
When I open the session, I immediately get disconnected.
Actually, it's not a network problem as the server is reached.
Bloomberg tells me that they have an "Unknown Protocol" message.
I don't get any log on my side.
Do you see something wrong in my configuration?
Is there someone that successfully set up a quickfix connection with Bloomberg? If yes what could be wrong in my settings from your experience?
You should put the SSL options under the session that it applies to. In your case:
[SESSION]
BeginString=FIX.4.4
SenderCompID=MY_COMP_ID
TargetCompID=BBG_COMP_ID
HeartBtInt=60
ValidateFieldsOutOfOrder=N
UseDataDictionary=Y
DataDictionary=FIX_BBG.xml
CheckLatency=N
SSLEnable=Y
SSLProtocols=Tls12
SSLValidateCertificates=Y
SSLCheckCertificateRevocation=N
SSLCertificate=C:\Services\FixEngineService\cert\pkcs12\cert.pfx
SSLCertificatePassword=xxxxxxxxxxxx
I post the config that worked for me. In case other people struggle with the same configuration issue.
[DEFAULT]
ConnectionType=initiator
ReconnectInterval=2
FileStorePath=store
FileLogPath=fixlog
StartTime=06:00:00
StartDay=monday
EndTime=22:00:00
EndDay=friday
SocketConnectHost=xxxx.xx.xxx.32
SocketConnectPort=8228
# standard config elements
[SESSION]
BeginString=FIX.4.4
SenderCompID=MAP_MY_BETA
TargetCompID=MAP_BLP_BETA
HeartBtInt=60
ValidateFieldsOutOfOrder=N
UseDataDictionary=Y
DataDictionary=FIX_BBG.xml
CheckLatency=N
SSLEnable=Y
SSLProtocols=Tls12
SSLValidateCertificates=N
SSLCheckCertificateRevocation=N
SSLCertificate=C:\Services\FixEngineService\cert\pem\cert.pem
SSLCertificatePassword=xxxxxxxxxx
SSLCACertificate=C:\Services\FixEngineService\cert\pem\CACerts.pem
SSLRequireClientCertificate=Y
Also don't forget to import the pfx certificat for the right user.
Best,
I want to send my weblogic log to syslog. here is what I have done so far.
1.Included following log4j.properties in managed server classpath -
log4j.rootLogger=DEBUG,syslog
log4j.appender.syslog=org.apache.log4j.net.SyslogAppender
log4j.appender.syslog.Threshold=DEBUG
log4j.appender.syslog.Facility=LOCAL7
log4j.appender.syslog.FacilityPrinting=false
log4j.appender.syslog.Header=true
log4j.appender.syslog.SyslogHost=localhost
log4j.appender.syslog.layout=org.apache.log4j.PatternLayout
log4j.appender.syslog.layout.ConversionPattern=[%p] %c:%L - %m%n
2. added following command to managed server arguments -
-Dlog4j.configuration=file :<path to log4j properties file> -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger -Dweblogic.log.Log4jLoggingEnabled=true
3. Added wllog4j.jar and llog4j-1.2.14.jar into domain's lib folder.
4.Then, from Admin console changed logging information by doing the following. "my_domain_name"--->Configuration--->Logging--->(Advanced options)-->Logging implementation: Log4J
Restart managed server.
I used this as refernce. But didnt get anaything in syslog(/var/log/message). What am I doing wrong?
I would recommend a couple items to check:
Remove the space in DEBUG, syslog in the file
Your last two server arguments have a space between the - and the D so make sure that wasn't just a copy and paste error in this post.
Double check that the log files are in the actual classpath.
Double check from a ps command, that the -D options made it correctly into the start command that was executed.
Make sure that the managed server has a copy of the JARs correctly as they would get synchornized from admin during the restart.
Hopefully something in there will help or give an idea of what to look for.
--John
I figured out the problem. My appender was working fine, the problem was in rsyslog.conf. Just uncommented following properties
# Provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514
We were appending the messages, but the listner was abesnt, so it didnt knew what to do with it.
and from *.debug;mail.none;authpriv.none;cron.none /var/log/messages it figures out where to redirect any (debug in this case) information to messages file.
I have an ear file that has a validation.xml file in one of its ejb modules when I want to deploy it on Weblogic 12.2.1, then the Weblogic throws the following exception:
<BEA-000000> <Error parsing validation.xml synchronously
java.lang.IllegalArgumentException: URI is not hierarchical
at java.io.File.<init>(File.java:418)
at org.eclipse.persistence.jaxb.ValidationXMLReader.parseValidationXML(ValidationXMLReader.java:147)
at org.eclipse.persistence.jaxb.ValidationXMLReader.call(ValidationXMLReader.java:67)
at org.eclipse.persistence.jaxb.BeanValidationHelper.parseValidationXml(BeanValidationHelper.java:178)
at org.eclipse.persistence.jaxb.BeanValidationHelper.getConstraintsMap(BeanValidationHelper.java:143)
at org.eclipse.persistence.jaxb.BeanValidationHelper.isConstrained(BeanValidationHelper.java:120)
at org.eclipse.persistence.jaxb.JAXBBeanValidator.isConstrainedObject(JAXBBeanValidator.java:255)
at org.eclipse.persistence.jaxb.JAXBBeanValidator.shouldValidate(JAXBBeanValidator.java:206)
at org.eclipse.persistence.jaxb.JAXBUnmarshaller.validateAndBuildJAXBElement(JAXBUnmarshaller.java:235)
at org.eclipse.persistence.jaxb.JAXBUnmarshaller.unmarshal(JAXBUnmarshaller.java:640)
at org.hibernate.validator.internal.util.privilegedactions.Unmarshal.run(Unmarshal.java:38)
at org.hibernate.validator.internal.util.privilegedactions.Unmarshal.run(Unmarshal.java:20)
at org.hibernate.validator.internal.xml.ValidationXmlParser.run(ValidationXmlParser.java:201)
at org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:125)
at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:81)
at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:353)
at org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:120)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at org.jboss.weld.util.ServiceLoader.prepareInstance(ServiceLoader.java:240)
at org.jboss.weld.util.ServiceLoader.loadService(ServiceLoader.java:214)
at org.jboss.weld.util.ServiceLoader.loadServiceFile(ServiceLoader.java:182)
at org.jboss.weld.util.ServiceLoader.reload(ServiceLoader.java:162)
at org.jboss.weld.util.ServiceLoader.iterator(ServiceLoader.java:297)
at com.oracle.injection.provider.weld.BasicDeployment.getExtensions(BasicDeployment.java:106)
at com.oracle.injection.provider.weld.WeldInjectionContainer.initialize(WeldInjectionContainer.java:92)
at com.oracle.injection.integration.CDIAppDeploymentExtension.initCdi(CDIAppDeploymentExtension.java:64)
at com.oracle.injection.integration.CDIAppDeploymentExtension.activate(CDIAppDeploymentExtension.java:41)
at weblogic.application.internal.flow.AppDeploymentExtensionFlow.activate(AppDeploymentExtensionFlow.java:39)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:753)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:263)
at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:67)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:601)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:171)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:121)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:343)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:895)
at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1422)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:454)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:181)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:195)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:13)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:68)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:643)
at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:348)
at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:333)
at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:54)
at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:617)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:397)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)
The validation.xml file's content shows in the below:
<?xml version="1.0" encoding="UTF-8" ?>
<validation-config
xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://jboss.org/xml/ns/javax/validation/configuration
validation-configuration-1.1.xsd"
version="1.1">
</validation-config>
How to deploy ear file with validation.xml on weblogic 12.2.1?
It drives me crazy too. I tried to downgrade bean validation to 1.0, but did not help.
Here they suggest to ignore it since it is warning only, set the logger to SEVERE level.
I had the same problem with web application.
In my case validation.xml was in one of my jars. I was able to fix the problem by moving the file directly to the war that was being deployed.
In case of ear file I believe the same solution should work.
I think this is a bug in EclipseLink/TopLink (which is used for JPA and JAXB binding in WLS 12.2.1 and upwards). I opened a FORUM entry in the EclipseLink forum: https://www.eclipse.org/forums/index.php/m/1759047/#msg_1759047
Summary: They try to read the validation.xml resource like this:
URL validationXml = Thread.currentThread().getContextClassLoader().getResource("META INF/validation.xml");
and then:
new File(validationXml.toURI())
but the toURI contains an URI that looks like this:
The URL.toString is: zip:/local/saladin/wls12/weblogic/12.2.1.0.0/domains/XXXX/servers/AdminServer/tmp/_WL_user/xxxx-application_1.5.5_dev-SNAPSHOT/s86txs/lib/xxx-xxxx-xxxxdatamodel-1.5.5_dev-SNAPSHOT.jar!/META-INF/validation.xml
So this is not a file, and therefore it cannot work.
The correct way would be to get the resource as Stream and not as File. But as to a solution, I don't know really how to fix it without modifying the EclipseLink source code. It is quite ugly to have those Warnings in the logfile and not being able to do anything about it.
I've spent quite a bit of time on this so here's where I'm stuck.
I'm using the debug player 10.1 to get an XMLA request from:
http://localhost/dir/blah.swf
to:
http://localhost/olapbin/msblah.dll
This worked fine in the filesystem, but now its on an IIS7 web server.
After a lot of fiddling with the crossdomain.xml file I settled on:
<?xml version="1.0"?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="*" to-ports="*" />
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
which is placed in:
http://localhost/crossdomain.xml
and read with:
Security.loadPolicyFile("http://localhost:80/crossdomain.xml");
I setup Policy file logging (which helped come up with the above file)
and on IE8 its all working just fine. I get:
OK: Root-level SWF loaded: http://127.0.0.1/akts/ThinSlicerRunner.swf
OK: Policy file accepted: http://localhost/crossdomain.xml
OK: Searching for <allow-access-from> in policy files to authorize data loading from resource at http://localhost/olapbin/msmdpump.dll by requestor from http://127.0.0.1/akts/ThinSlicerRunner.swf
OK: Searching for <allow-http-request-headers-from> in policy files to authorize header sending to URL http://localhost/olapbin/msmdpump.dll by requestor from http://127.0.0.1/akts/ThinSlicerRunner.swf
OK: Request for resource at http://localhost/olapbin/msmdpump.dll by requestor from http://127.0.0.1/akts/ThinSlicerRunner.swf is permitted due to policy file at http://localhost/crossdomain.xml
On Chrome and Firefox I just get:
OK: Root-level SWF loaded: http://localhost/akts/ThinSlicerRunner.swf
OK: Policy file accepted: http://localhost/crossdomain.xml
and nothing else... no attempts to authorize the httpservice requests.
In the main flex error log I get:
*** Security Sandbox Violation ***
Connection to
http://localhost/olapbin/msmdpump.dll
halted - not permitted from http://localhost/akts/ThinSlicerRunner.swf
Which doesn't appear when I run the same thing from IE8.
Any idea what's going on ??
AS REQUESTED... MORE CODE
Main sending request:
var connection:TsConnection = this.__connection;
var token:AsyncToken = new AsyncToken(null);
connection.service.request = this.__curSoapRequest;
var actualToken:AsyncToken = connection.service.send();
__tokenArr.push(actualToken);
var responder:AsyncResponder = new AsyncResponder(resultHandler, faultHandler, actualToken);
__responderArr.push(responder);
actualToken.addResponder(responder);
Connection object highlights:
public function init():void {
//Initialize the service object needed to query the server
this.__service = new HTTPService;
this.__service.method = "POST";
this.__service.contentType = "application/xml";
this.__service.resultFormat = "e4x";
this.__service.headers = getHeaders();
this.__service.url = this.__model.xmlaUrl;
this.__initialized = true;
}
public function get service():HTTPService {
return this.__service;
}
private function getHeaders():Object {
var o:Object = {};
o["SOAPAction"] = '"urn:schemas-microsoft-com:xml-analysis:Discover"';
o["Content-Type"] = "text/xml";
return o;
}
Thanks for your help ... hope this helps others when fixed. ;-)
Shaun
http://www.vidgridz.com/
Thanks for everyone's answers. It was indeed able to be solved in the code
even if it wasn't exactly a true coding problem.
Here is the xml data file I was reading the configuration details from:
<tsConnection>
<dataSource>megan</dataSource>
<database>Adventure Works DW 2008</database>
<cube>Adventure Works</cube>
<xmlaUrl><![CDATA[
http://localhost/olapbin/msmdpump.dll
]]></xmlaUrl>
</tsConnection>
Now on the "localTrusted" or "localWithNetworking" setup, this was working just fine.
It also works on the IE8 Flash player even in "remote".
However, what was happening was that the xmlaUrl was being read as:
\n\rhttp://localhost/olapbin/msmdpump.dll
(with the newline and carriage return at the start)
This is was what was confusing the domain checking and throwing a Sandbox Violation
when run in the "remote" security sandbox.
Of course, my xml should have been better, and maybe put in some ignore white
space processing in the code, but still its quite some bizarre, inconsistent
behavior from the Flash player code in Netscape compatible browsers (10.1.x).
So the final, working solution looks like this:
<tsConnection>
<dataSource>megan</dataSource>
<database>Adventure Works DW 2008</database>
<cube>Adventure Works</cube>
<xmlaUrl><![CDATA[http://localhost/olapbin/msmdpump.dll]]></xmlaUrl>
</tsConnection>
I did become a crossdomain.xml expert in the process though. ;-)
Although, now I don't need the file at all.
Bear it in mind if you see some crazy unexplained Sandbox Violations, check for
white space in your service url.
If your DLL backend service and SWF are served from the same domain, it should be allowed. Nothing in the crossdomain.xml file should apply. You should not have to load the crossdomain file manually either. It sounds like that is what you're trying to do.
I suspect something else is going on with your code.