I am attempting to subscribe to certain message types from one of our providers. I send the 35=BW message as per their API, and I receive all the Quote messages that I need.
However, I can only see them in the quickfix generated log, they are not passing through the fromApp() method. Anyone know why that is?
Here are the full messages from the quickfix logs:
8=FIXT.1.1|9=101|35=A|34=1|49=ME|52=20190801-21:24:08.974|56=THEM|98=0|108=30|141=Y|1137=9|10=209|
8=FIXT.1.1|9=97|35=A|56=ME|49=THEM|52=20190801-21:24:09|34=1|108=30|141=Y|98=0|1137=9|10=222|
8=FIXT.1.1|9=159|35=BW|34=2|49=ME|52=20190801-21:24:09.165|56=THEM|1346=bc445475-6c3d-49b1-8e69-1fae46fbaa2b|1347=1|1351=1|ApplID=quotes|1357=0|1399=0|10=048|
8=FIXT.1.1|9=129|35=BX|49=THEM|56=ME|34=2|52=20190801-21:24:09|1346=bc445475-6c3d-49b1-8e69-1fae46fbaa2b|1347=1|1348=0|10=058|
8=FIXT.1.1|9=316|35=S|49=THEM|56=ME|34=3|52=20190801-21:24:09|1180=ApplID|1181=0|60=20190730-18:38:13.068519|131=1564181552814-51|117=8SVc72UWLVQ|55=USD/CAD|64=20190731|63=SPOT|453=1|448=AUTO|447=D|452=61|2376=18|132=1.3158|133=1.31586|134=1000000|135=1000000|8021=USD|8022=USD|2533=0|9501=0|2534=0|9502=0|10=061|
8=FIXT.1.1|9=159|35=BW|34=3|49=ME|52=20190801-21:24:14.165|56=THEM|1346=859f354c-6c3f-48dd-880c-435eb5241ab0|1347=4|1351=1|1355=ApplID|1357=0|1399=0|10=163|
The messages that I do not receive through my fromApp() method are the Quote as well as the 35=BX messages (both application layer basically)
And here are my quickfix settings
[DEFAULT]
# Settings which apply to all the Sessions.
ConnectionType=initiator
SenderCompID=ME
ReconnectInterval=30
HeartBtInt=30
FileStorePath=/my/log/path
FileLogPath=/my/log/path
FileLogHeartBeats=Y
[SESSION]
# Settings specifically for one session
BeginString=FIXT.1.1
DefaultApplVerID=FIX.5.0SP2
AppDataDictionary=MyDictionary.xml
TransportDataDictionary=MyTransportDictionary.xml
TargetCompID=THEM
TimeZone=America/New_York
StartTime=06:00:00 US/Central
EndTime=19:00:00 US/Central
Weekdays=Mon,Tue,Wed,Thu,Fri
SocketConnectPort=theirPort
SocketConnectHost=their.ip.address
UseDataDictionary=Y
CheckLatency=N
ResetOnLogon=Y
Any help greatly appreciated
EDIT: I put a breakpoint on the Session.next() method, and it's only being called for the 35=A LOGON message. No application layer messages ever go through it, but they are definitely being saved in the quickfix logs. I tried by sending multiple other subscriptions with the same outcome.
Related
I use keycloak to reset a user's password through a custom flow.
The flow works for resetting the password and logging/auditing error events.
But the context.success() doesn't log events in EVENT_ENTITY. I tried changing the event type to try and find the root cause using
context.getEvent().event(EventType.SEND_RESET_PASSWORD_ERROR); // for eg. context.success();
I am not sure what the problem is, or fail to understand what is different from setting a success and error.
I found the issue and it was me missing a call to send the event on success.
on error on context.getEvent().error(..) which call EventBuilder.send() internally. I had to use context.getEvent().sucess() to save the event on success.
Trying to retrofit an old webforms application.
Got my configuration working so that it's prompting for login and successfully redirecting back to the application. The folks that manage the IP can see the response is generated.
However in the callback to my application the User is null. I'm told if it's configured correctly it should be populated.
We have a custom IHttpModule and that is where I can see getting hit with the call to /Saml2/Acs with the User not populated. I think this may be expected as the handler for that is supposed to populate the User, I think? However the following call (the returnUrl configured in sustainsys.Saml2) still has no User and I don't see any sort of error or anything.
Anyone with experience have an idea how to debug this?
The call to /Saml2/Acs should be taken care of by the Sustainsys.Saml2.HttpModule. It will process the response and then call the SessionAuthenticationModule to set a cookie that preservers the User across calls.
To get some more information about what's happening in the library, you can assign an implementation of ILoggerAdapter to Sustainsys.Saml2.Configuration.Options.FromConfiguration.SPOPtions.Logger to get some logging output from the library.
My issue turned out to be that I had another authentication module loaded before SessionAuthenticationModule and Saml2AuthenticationModule in the web config.
The comment in the example was
Add these modules below any existing. The SessionAuthenticatioModule
must be loaded before the Saml2AuthenticationModule
However in my case with I had another authentication module involved that needed to go last.
I've been playing around with building some realtime functionality using Sails.js version 0.10-rc5 (currently the #beta release).
To accomplish anything, i've been following the sweet SailsCast tutorial on this subject (sailsCast link)
It talks about subscribing to a model via a 'subscribe' action within the model's controller. Then listening to it at the client side, waiting for the server to emit messages. Quite straightforward, although I do not seem to receive any messages.
I'm trying to do this to get real-time updates on anything that changes in my User models, or if new ones get created.. So I can display login status etc. in real time. Pretty much exactly the stuff that's explained in the sailsCast.
In my terminal i'll get two things worth noticing, of which the first is the following:
debug: Deprecated: `Model.subscribe(socket, null, ...)`
debug: See http://links.sailsjs.org/docs/config/pubsub
debug: (⌘ + double-click to open link from terminal)
debug: Please use instance rooms instead (or raw sails.sockets.*() methods.)
It seems like the 'subscribe' method has been deprecated. Could anybody tell me if that's correct, and tell me how to fix this? I've been checking out the reference to the documentation in the debug message, although it just points me to the global documentation page. I've been searching for an answer elsewhere, but haven't found anything useful.
The second message I'm getting is:
warn: You are trying to render a view (_session/new), but Sails doesn't support rendering views over Socket.io... yet!
You might consider serving your HTML view normally, then fetching data with sockets in your client-side JavaScript.
If you didn't intend to serve a view here, you might look into content-negotiation
to handle AJAX/socket requests explictly, instead of `res.redirect()`/`res.view()`.
Now, i'm quite sure this is because I have an 'isAuthenticated' policy added to all of my controllers and actions. When a user is not authenticated, it'll redirect to a session/new page. Somebody must log in to be able to use the application. When I remove the 'isAuthenticated' policy from the 'subscribed' action, the warnings disappear. Although that means anyone will get updates via sockets (when I get it to work), even when they're logged out. - I don't really feel like people just sitting at the login screen, fishing out the real time messages which are intended only for users who are logged in.
Can anyone help me getting the real time updates to work? I'd really appreciate!
As far as the socket messages not being received, the issue is that you're following a tutorial for v0.9.x, but you're using a beta version of Sails in which PubSub has gone through some changes. That's covered in this answer about the "create" events not being received.
Your second issue isn't about sockets at all; you'll just need to reconsider your architecture a bit. If you want to to use socket requests to sign users in, then you'll have to be more careful about redirecting them because, as the message states, you can't render a view over a socket. Technically you could send a bunch of HTML back to the client over a socket, and replace your current page with it, but that's not very good practice. What you can do instead is, in your isAuthenticated policy, check whether the request is happening via sockets (using req.isSocket) and if so, send back a message that the front end can interpret to mean, "you should redirect to the login page now". Something like:
module.exports = function (req, res, next) {
if ([your auth logic here]) {
return next();
}
else {
if (req.isSocket) {
return res.json({status: 403, redirectTo: "/session/new"});
} else {
return res.redirect("/session/new");
}
}
}
I'm using Liferay 6.1.20 and my Portlet is using the Liferay Mail Service to send an E-Mail via the in Liferay configured SMTP-Server.
My Question is now: is it possible to check whether the SMTP-Server is available or is it possbile to check whether the E-Mail was successfully sent? If the SMTP-Server is not available I want to give an output to the User. Actually I only see the following line in the server console:
14:06:47,679 WARN [liferay/mail-1][MailEngine:560] Failed to connect to a valid mail server. Please make sure one is properly configured. Could not connect to SMTP host: localhost, port: 25
I hope someone can give me a solution for that. Thanks!
basically there are two problems which prevent you to discover if any failure occurred when sending e-mails with MailServiceUtil service.
Firstly messages are sent asynchronously over Liferay message bus, so the user gets faster response but you never know if anything failed on the way.
Secondly messages eventually get to MailEngine where all exceptions get caught and are only written to the log.
So, I suggest you to override MailEngine class with ext-plugin (it's in util-java) to handle exceptions differently and then use it directly from your plugin instead of MailServiceUtil which only pushes all to the message bus.
Since Liferay 6.2, if you set mail.throws.exception.on.failure=true in your portal-ext.properties file, the MailEngine class will also throw a com.liferay.util.mail.MailEngineException on errors, instead of just logging.
A really old question, but as I kept arriving here, I am leaving this to anyone that may need (tested on 7.3).
We can test if the mail flow is normal with the following Groovy script:
import com.liferay.mail.kernel.service.MailServiceUtil
import javax.mail.*
import javax.mail.internet.*
import com.liferay.mail.kernel.model.MailMessage;
def from = new InternetAddress("no-reply#example.com")
def to = new InternetAddress ("where#example.com")
def mail = new MailMessage(from, to, "subject", "test message", false)
MailServiceUtil.sendEmail(mail)
And, as mentioned in the other answer, the property to view exceptions is still valid.
mail.throws.exception.on.failure=true
I want to give everyone who subscribes to a node the ability to both read and write to that node.
Joe created the node "test5" in the code below. When Mark tries to post, I get an error.
I am using XMPPFramework for iphone. I receive the following error IQ. It appears that openfire is telling me that I can't publish an item b/c I don't have access? What is the default access model, open?
Doesn't that mean that anyone can subscribe to the node "test5", and anyone can publish items to it?
The JID of the fake user who originally created node "tes5" is "mark#joes-macbook-air.local"
Could the unauthorized message posting be b/c mark is not the owner of node titled "test5"?
What if I want mark to be able to post to this feed as well?
<iq xmlns="jabber:client" type="error" from="pubsub.joes-macbook-air.local" to="joe#joes-macbook-air.local/838f75ba"><pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="test5"><item><body>Helpl me</body></item></publish>
</pubsub><error code="403" type="auth">
<forbidden xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
</error>
</iq>
Update: I made the subscriber a "publisher". This is done by altering the publish_model of the node.
This depends on the node configurations in your pubsub service. Particularly the access mode of your node. In the XEP-0060 the access models section gives a good explanation on the different access methods. (1) The one you need in your case will be the "Open" which is defined as "Any entity may subscribe to the node (i.e., without the necessity for subscription approval) and any entity may retrieve items from the node (i.e., without being subscribed); this SHOULD be the default access model for generic pubsub services."
I hope this gives a clear answer to your question.