I bought bitrix self host version then I installed it to my server.
But when checking I see all message interact with Bot Framwork all through to bitrix server: im.bitrix.info, can I setup a application as im.bitrix.info by my self at my own server for controlling.
I need it because many cases I can debug what problem with skype bot or bitrix problem.
Unfortunately, no.
Some organizations may restrict Internet access due to security reasons. In this case Firewall controls the incoming and outgoing network traffic based on predetermined security rules. In order to to be able to work with your Bitrix24 account, please make sure you have the following addresses allowed in your Firewall: *.bitrix24.com, *.bitrix24.net (Bitrix24.Network, authorization)
International domains:
*.bitrix24.de (Germany)
*.bitrix24.es (Spanish speaking countries)
*.bitrix24.com.br (Portuguese speaking countries)
*.bitrix24.cn (China)
*.bitrix24.in (India)
*.bitrix24.eu (Europe)
*.bitrix24.fr (France)
For all of the above mentioned addresses we recommend to allow subnet mask *.bitrix24.*.
Please note that the following addresses should be allowed as well in order to provide simaltaneous work of such services as telephony, bots, open channels, videos: *.bitrix.info, bitrix*.cdnvideo.ru, *.cloudfront.net
https://helpdesk.bitrix24.com/open/6355275/
Bitrix telephony, bots, open channels and videos work through the cloud server.
Related
Once, we were having a conversation with our computer science professor about Wireshark and he told us, how he previously used it in a class and even saw facebook chats of some of his students. As I know, facebook is encrypted, so does anybody have an idea how he was able to do that?
Yes. Prior to the release of the tool FireSheep, Facebook, LinkedIn, Twitter, and other prominent social media platforms did not support TLS/SSL for all connections. In fact, companies generally claimed that the processing overhead would be too high, limiting their ability to serve customers effectively.
When FireSheep was released, most major social networking providers completely switched to TLS, or at least made it available for all requests, within weeks. Your professor likely did his demonstration before this change was made.
If you're unfamiliar with FireSheep, it was a Firefox browser plugin that allowed you to automate the collection of other user's session IDs from network traffic (via a network sniffer), allowing you to instantly impersonate any user (whose network data you could see) on major social media platforms.
We have an enterprise installation of QuickBlox (which implements XMPP), and would like to create mirrored accounts for all of our users on our QuickBlox server install. We also want to sync the networks our system's users have created using relationships (eg, "client and provider") that have been built on our system.
In a nutshell, we want to export whitelists that limit chat "opponents" to only those users with whom each of our users already have relationships. If User1 has an existing relationship in our system with User2 and User3 but not User4 through User40, we want to be able to use the QuickBlox API to enforce that within chat by creating a whitelist through the QuickBlox API.
EDIT: We can't use an "honor system" whitelist. That is, the enforcement must be server-side using a method the client cannot circumvent. There must be a hard, unavoidable block between users for privacy concerns.
Use case:
A QuickBlox (or XMPP) server has User1 through User40, inclusive.
User1's whitelist is comprised of [User2, User3] only.
If User1 attempts to contact User15, we want QuickBlox/XMPP to note that User15 is not on User1's whitelist and block that communication as if User1 had bidirectionally blocked that user.
Privacy lists, aka blacklists
I have found places in QB's docs that refer to the XMPP specification docs, and have found the concept of privacy lists, which seem to operate as blacklists:
https://quickblox.com/developers/Web_XMPP_Chat_Sample#Privacy_lists
https://xmpp.org/extensions/xep-0016.html#protocol-syntax
These only provide two styles of blacklist privacy:
You can choose a type of blocked logic (Privacy List). There are 2
types:
Block in one way. You are blocked, but you can write to
blocked user.
Block in two ways. You are blocked and you also can't
write to blocked user.
Server Whitelist (dialog-level, not user)
I've also found documentation on whitelists for servers, which appear to operate at a dialog/jid, not user, level:
https://xmpp.org/extensions/xep-0133.html#edit-whitelist
An entity added to a whitelist MAY be a JID of any form as specified in RFC 6120... a whitelist may prevent inbound communications, outbound communications, or both...
Rosters -- "presence" detail only?
There are also rosters, which are close to whitelists, but they do not seem in my testing to restrict communication between any two users that might not be on each other's roster.
https://quickblox.com/developers/Web_XMPP_Chat_Sample#Get_the_roster
That is to say, I haven't set up a roster in my testing application, and users are able to create group and 1-on-1 chat dialogs in spite of not having explicitly accepted any roster requests. In the Android docs, I found the following on rosters: "[A roster] is the collection of users a person receives presence updates for." That's not blocking in any way outside of presence alerts, I don't believe.
Question
Is there a suggested way to create a pessimistic whitelist for each user, which only contain those users with whom communication is allowed? Or are we forced to create and maintain "inverse blacklists", where we automate the creation of privacy lists for every new user blocking every other user and then use the API to remove those with which each user should be able to communicate?
If we do have to use "inverse blacklists", is there a way to have a default blacklist apply to every new user that initially blocks communication with every other user already in our QuickBlox system?
(Again, we can't use "honor system" lists. If the client must request a whitelist to be active before it can be used, can freely discover and then change active whitelists, or if the client can decline to use a list, that's not secure enough.)
XMPP Clients
XMPP clients will need a way to ask another clients if they support receiving pushes via a relay. Since pushes can be sent from anywhere, clients will also be able to send pushes directly to other clients through the relay as long as they have their friend’s whitelist token. They will also need to respond to XMPP server inquiries for whitelist tokens to allow pushes to be sent by the server if a message is sent by a client not supporting direct push.
XMPP Servers
XMPP servers can ask their connected clients if they support push relays and, if so, forward messages they receive to the push relay server when the client is offline. This will require the XMPP server to obtain a whitelist token from the user as well.
Help:see this link
If we are talking about XMPP protocol - there is an ability to block any communications from/to (see example 48)
So, by default, you can set it for each user for example.
Then, if we need to allow to communicate with someone specific,
then you can add this user to your privacy list with action=allow and order greater than 'full block'. Here is actually a good example of whitelist implementation via Privacy Lists, see example 8:
and (3) 'special', which allows communications only with three
specific entities.
One of our hotel clients provide free WiFi to its guests with a Hot Spot, however, there are available only a few URL to access them freely (such as Facebook or the website of the hotel) and if you need more access you should log in.
We have developed the App for the hotel and one of its features is that if you open the App it gives you a complete access to the hotel WiFi, so you can navigate to any page you want.
Therefore, it is necessary that the guests can download the app through the AppStore without being logged in to the hotel WiFi, so the guest can download the App and get the access immediately.
We have a trace of the URL that calls the AppStore for search and downloading the App and we have set the Hot Spot to allow access to this URL, however, the AppStore tells us that we have no connection.
What URL should we need to enable in our Hot Spot for the AppStore to work properly?
These are the routes that have enabled:
search.itunes.apple.com
play.itunes.apple.com
init.itunes.apple.com
su.itunes.apple.com
itunes.apple.com
se.itunes.apple.com
p59-buy.itunes.apple.com
pd-st.itunes.apple.com
xp.apple.com
sp.itunes.apple.com
Thank you for your help.
Apple Appstore communicate using HTTPS. So router in the middle will not know what url that been use by client due to it's encrypted.
The solution is, instead of allow those by url. you need to allow it by ip address.
I would suggest to allow connection to the following address.
17.154.0.0/16 Apple's Class B Subnet includes phobos.apple.com address(es)
23.63.98.0/23 Akamai Technologies CDN
Please keep in mind that xxx.xxx.xxx.xxx/16 mean 255.255.0.0.
And it will be equal to allow ip adresss from 17.154.0.0 - 17.154.255.255
Also Akamai is a Content delivery service So ip address will various from location. I would suggest you to try to ping swcdn.apple.com get ipaddress and allow those /23 server.
We are developing a consumer hardware product. Each device is registered on a central webserver and the owner also have a user account to which the device is linked. The owner may also choose to share the device with other users.
Now, to solve the problem of getting through firewalls etc we are using XMPP: the user access his/her devices using an iOS/Android app. The app connects to the XMPP-server and so does the hardware devices. So the app can access the devices by sending custom XMPP stanzas.
Currently the device and the mobile app use the same JID, so the device will allow messages only from the same bare JID as itself uses. To allow for sharing devices we are planning to use the roster instead: the device will get its own JID ("hw381983829#thexmppserver.com") and will accept stanzas from all JID's in its roster.
The problem I'm having is that the users, devices and device-sharing data are stored on the webserver. I would like to use this same information on the XMPP-server: all users and devices on the webserver are allowed to login to XMPP and the roster of a device is the same as the users that may access it. This information can be accessed through a JSON API.
One way would be to mirror changes as they happen, but I don't like that idea since there are too many steps that could go wrong.
The best solution I can think of is to let the XMPP server use the JSON API instead of its builtin database. It would be read-only, but that is not a problem since all registration and sharing should be done on the webserver.
Any ideas on how to proceed? The functionality described above is more or less all that we need: we don't need S2S, offline messages, etc. We are currently using Ejabberd, but Prosody or Openfire are perhaps better alternatives?
For authentication, it looks like this ejabberd contribution does exactly what you need:
https://github.com/processone/ejabberd-contrib/tree/master/ejabberd_auth_http
For roster, it is easy to write a custom roster module that will be hitting your HTTP backend instead of query the database thanks to ejabberd API.
You can have a look at mod_roster as a guide to implement the methods: https://github.com/processone/ejabberd/blob/master/src/mod_roster.erl
I'm working on an iphone app and will be using a 3rd party advertising services. The advertisting service want me to provide them with the users IP address via an API call. This is so the ad service can track users across web and app.
So is the IP address counted as device information? Do apple policies allow me to share the IP address with a 3rd party? My privacy policy will indicate that I'm collecting and passing on the IP address.
Thanks.
Any time your application makes a HTTP request, the receiving web server will get the calling device's IP address. That's the nature of the beast.
Thousands of iOS applications make external HTTP requests and don't provide a custom EULA (look at all the apps out there with ads in them).
So, it is obviously not against Apple's policies. IP addresses are not technically personally identifiable information.
However, you should not share the device's unique identifier (found by doing [[UIDevice currentDevice] uniqueIdentifier]) because that is considered personally identifiable information and could be use to track a specific user. It may not be against Apple's policy, but it is likely illegal in the USA unless you provide a sufficient EULA.