According to XEP-0220 the Authoritative-Server receives via a new connection db:verify and sends a go or no-go back to the Receiving-Server.
How can he send the db:verify to an other server without having a established connection?
According to the RFC a proper XMPP stream is initialized by stream:stream and stream:features. But then we are stuck in a loop cause he wants to authenticate again.
I am pretty sure I missed something here. I appreciate any help.
Cheers
Answer and quote from jabber mailing list:
You have to distinguish between authenticated and unauthenticated
streams. You can, and in fact have to, exchange dialback elements over
unauthenticated streams. So there is no loop.
I missed the point that only <message/>, <presence/> and <iq/> require authentication.
Related
I am interested in having a mix of encrypted and plaintext topics on the same Kafka cluster. Some topics would be accesible through plaintext protocol while others would (must) not.
I have been going through Kafka encryption with SSL documentation and several other entries through the web, and I have the impression that a per topic security configuration might not be supported out of the box with simple configuration, but would like to validate this impression with more experienced people.
All related documentation I find shows how to enable secured and plaintext protocols for the whole cluster, but I could not find any way to do so per topic. Is that currently possible? Perhaps by implementing a custom Authorizer class, although ideally I was looking for something more "out of the box", like a simple topic configuration which would specifically indicate which protocols this topic would support.
Thanks in advance.
#JPS
i think you might mix things up here. What exactly do you want to achive?
The link from your initial post refers to a documentation, how to set up ssl-in-flight-encryption and/or authentication with your kafka-cluster. But this does not alter the data, that is written into your topics. Kafka does not provide an out-of-the-box "data-at-rest-encryption"-solution. So, what is it exactly?
I am building a WebRTC app where two users are selected at random and then connect to each other to chat. Both clients keep an open WebSocket connection and I am planning to use this to exchange their offers/answers to signal a connection. The case I am trying to account for is when there is a peer that intentionally sends bad configuration information, and also when the peer might spontaneously disconnect in the middle of the signaling exchange.
My solution to the first case is have the server keep state of the exchange, so when the connection is first established I would expect that user A provide an offer and user B have an answer. Is this appropriate? or should this be implemented exclusively client side?
My solution to the second problem feels to me like a hack. What I am trying to do is notify the user that a match has been made and then the user will set a timeout say 20 seconds, if a connection hasn't been made in that amount of time then it should move on...
Are these appropriate solutions? How do you reliably establish a WebRTC when either peer can't be trusted? Should the signaling server be concerned with the state of the exchange?
Sounds like you're more concerned about call set up errors rather than being able to trust the identity of the remote peer. They are two very different problems.
Assuming it is the call set up errors you are concerned about you shouldn't be trying to avoid them you should be trying to make sure your application can handle them. Network connection issues are something that will always crop up and need to be handled.
Setting a timer for the establishment of a WebRTC call to complete is a logical solution. Displaying a warning to the user that the time limit is approaching also seems like a good idea. SIP is a signalling protocol and it has a defined timeout for the completion of a transaction and if it doesn't complete within that time it will generate an error response. You could use the same approach.
I have a project coming up where I need to send and receive messages through a specific mobile operator, which only provides an SMPP interface. The whole project will be a hosted website. I have already read quite a lot, but I do not yet quite understand what is actually needed from my side to use the protocol.
Should my application try to maintain a constant connection to the smpp?
Can I simply connect, send a message and then disconnect?
Are receiving messages based on push or pull?
Thanks for the help.
SMPP is a peer-to-peer protocol. That should mean that SMS Gateway (your side) and SMSC (your mobile operator) need to have a proper bind/connection established. Even when there are no SMS or DLRs to send/receive, there is a continous exchange of smpp PDU (enquire_link/enquire-link_resp) that ensure that the bind is established.
In detail, if you send an enquire_link PDU and you get no response (enquire_link_resp) the bind is broken. Your sms won't be delivered (will remain enqueued in your gateway store), and you won't receive MOs (incoming sms) or DLRs (delivery report). To re-establish the connection you should re-initiate the connection.
So, my answer would be that you need a constant connection to SMSC.
You are stating you want to receive messages, as a result at least a bind_receiver is needed. Because you don't know when messages are going to come in, you will have to be constantly connected, rather than disconnecting after each event.
With regards to your question about "push or pull" this depends on how you solve the first problem. If you can build a solution that is constantly connected, the result will be a push (the carrier will push it to you as soon as they receive the message). If (for some reason) you cannot maintain a constant connection, you'll end up building a pull mechanism. You'll connect to the carrier ever X seconds to see if they have a message waiting for you.
I do need to highlight 2 pitfalls though:
A number of carriers in the world, do not store or even accept messages if you are not connected, therefore, depending on which carrier you interact with, you might be forced to use a continuous connection.
Most carriers do not allow you to open and close connections in quick succession. Once you disconnect, you can not reconnect for a time frame of X seconds.
Therefore a constant connection is really the way to go. Alternatively, you can look into a company like Nexmo, which will provide you with a HTTP Call every time a message arrives.
I'm not sure which language your developing your application in, but if you use any of the popular languages (Java, PHP, Perl) there are modules out there that handle basic SMPP Connectivity for you. A quick google search for your language and "SMPP Client" will give you a list of references.
I'm trying to set up a client-server architecture. I have one GKSession configured as a server, and two others as clients.
When either client uses the sendData:toAllPeers:WithDataMode:error method, it sends it not only to the server but to the other client.
I guess I could use the display name to exclude clients, so client data only goes to the server, but I'm not quite following why this is happening.
My server explicitly accepts a connection, via acceptConnectionFromPeer:error: But my client isn't accepting anything from anybody, it seems to be just silently finding the other client.
Should this be happening? I understand in a peer-peer setup you'd want peers to just find others; but in client-server, this seems a little weird.
Any clarification or advice would be greatly appreciated.
While a client cannot explicitly connect to another client, but the method sendData:toPeers:withDataMode:error: should allows you to send data directly from one client to another given that you have the correct peerId.
For what ever reason, a critical third peaty webservice functions like this. I can connect, send a request, and receive valid response, but i still get the error message. This only happens on one server.
"The incoming message was signed with a token which was different fron what used to encrypt the body. This was not expected." (sic)
This only happens on one server, but it's critical that I get the data. I don't have control over the server and while I'm aware what the message means, frankly I don't care. It's their call how they configure their own servers and send back the proper information. All I want is the data.
Is there any "shut up and deal with it" security setting in WCF so I can get data properly from the server?
What kind of tokens are you using? Certificates? If so, this article might be useful: "How to: use different X509 Certificates for signing and encryption". In particular, look at the part that reads "To use multiple certificates on the client".
I had to open up a trouble ticket with Microsoft to solve this. Those guys are good and it raised up pretty high up the chain.
In the end it was something simple - the certificate on my machine was somehow corrupt. I had delete it and reinstall it then everything magically began to work.