After the installation of ejabberd, and configure to the domain. I add the mod_blocking to block users, and it works.
The problem is that when one user open a chat with another user (from the same domain), can send message. In my case, only will be valid that the user receive messages from his friend list. The user could accept request from other users, before receive texts.
Any idea of how can I configure ejabberd to this functionality? (I think that is normal, but I can't find anything similar)
Thanks a lot!!
There is not default feature in XMPP to block message only from friend list. Even if you do that to avoid spam, a user can probably still spam by sending contact request with message.
Anyway, you will have to develop a custom module for that.
Related
I have a social media app written in Flutter. Users can see the profiles each other and block/unblock them. I'm using MySQL to keep that data. Now I want to implement chat feature using Firebase Firestore (or maybe MongoDB). When a user sends a message to another user, should I check if user blocked another user from MySQL every time, so user can't send new message. Is this a good practice in chat application, or should I store the "blocked" data at Firebase also.
I researched this subject deeply but didn't find any solution.
Like when user is trying to send a message to another user so in the list of the recipients you are also retrieving the value for (is particular user is blocked by the current user), if it's so you are checking this on that time.
Secondly, if you want this to check when sending to server. So, you can manage this using firestore transaction in which you might get the object of the sender and check to whom the sender has blocked and you may throw an exception. The other thing you might manage it using Firestore Security Rules as well.
So you can code like most of the current social media works.
Simply let the user send a message but put a condition on the receiver
user side so if the user is blocked by the receiver then it should not show
the chat in the user chat list also should not send a notification if the user
is blocked by the receiver.
I'm working on a project that consumes Service Now API (Rest). To do so our client has registered us as a user in order to login and make all service calls we need to. This project has an interface where users can login once they have an account on Service Now as well, the username they type to log in has nothing to do with service now by the way, but later they associate theirs service now users to it. They can do some operations through this interface, where all of them are done using the integration user/pass not their service now users theirselves, even because they do not need to share their passwords with us. But it's needed to track the correct user to register on service now and I'm in trouble specifically about commenting on an incident. The endpoint to comment is the following :
http://hostname/api/now/table/incident/{sys_id}
where request body is a json object just as simple as :
{
"comments": "My comment is foo bar"
}
but when this comment is registered on Service Now it is under integration user instead the user which commented. Is there any way I could keep a specific user, considering I already have the user id on Service Now ready to inform it on the request the way it should be.
I tried reading Service Now documentation but had no clue how to solve it, altought I've found something about impersonate
This is happening because you're being proxied through the "Integration User" instead of your own account. As long as this is the case, your comments are going to be attributed to the Integration User.
I can think of two ways to fix this issue.
Ask the client to log you into their system directly as a user.
Implement a special API (Scripted REST API, available in Geneva or later) that allows you to identify the Incident and enter the comment, and then the script forges the comment on your behalf, attributing authorship correctly.
The first solution can be expensive due to possible additional licensing costs.
The second solution will require a willing client to devote 2-3 hours of development time, depending on the programmer.
Firstly, you need an integration user with suffient rights. Our integration user has suffient rights out of the box, but your story could be different. A quick check is to try impersonate as other user using menu.
Login as integration user to ServiceNow instance.
Go to https://{instance}.service-now.com/nav_to.do
Click on username at top right corner. This is a drop down.
There should be at least three menu items: "Profile", "Impersonate User", and "Logout". If you do not have "Impersonate User" in this menu, your integration user miss some permissions. Contact system administrator if you miss this menu item to configure appropriate permissions.
Then you need to find sys_id of user that you want to impersonate. For example:
https://{instance}.service-now.com/api/now/table/sys_user?sysparm_query=user_name={username}&sysparm_fields=sys_id
If you have suffient privileges, you could invoke the folling endpoint with sys id of user that you want to impersonate:
HTTP POST to https://{instance}.service-now.com/api/now/ui/impersonate/{user_sys_id} with body "{}" and content type "application/json". You need to provide HTTP basic authentication to this query as your integration user.
The response code on success is 200. The response body could be ignored. The interesting result of this response is a set of cookies for impersonated user in response headers. These cookies could be used for subsequent REST API calls until they expire. Use some HTTP rest client dependent method to capture them and to provide them to next calls.
For Apache HTTP Client (Java), I'm creating http client context using:
HttpClientContext context = HttpClientContext.create();
context.setCookieStore(new BasicCookieStore());
Pass thing context to impersonation request and to subsequent API calls until I get 401 reply, after that I'm reaquiring cookies. Setting new cookie store is important, as otherwise some default cookies store is used.
Two things to note:
This API looks like internal one, so it could change at any time. If it happens, look for what "Impresonate User" menu item does, and repeat it youselves.
ServiceNow permissions are quite fine-grained, so the target user could lack permissions to perform operation. In some cases, if there is no permission to update the field the operation PATCH on object returns reponse 200, but field is not updated. This introduces a surprising mode of failure when you use impersonation.
What is the ejabbered behavior for user who is un-expectedly disconnected from internet
vs
user who explicitly sent an 'unavailable' presence?
Would they both be considered offline (for both single user chat or MUC)?
I want a behavior where if a user is disconnected from internet, offline messages to be sent
If user sent a explicit unavailble presence, I dont want offline messages to be sent.
How can that be accomplished? I can write my hook. But I need to know in which situations, the hook will be called.
When the user gets offline, the default behaviour is the same, no matter which method is used (explicit session close or unvoluntary disconnect). This is per XMPP specification.
If you want to customise the behaviour, it will not be easy as there is no way to know the reason why a user if offline.
What I would do: I would use the last module and support an optional reason for disconnect and store it. When you disconnect unvoluntarily, I would modify code to store reason being something like "timeout". When you disconnect explicitely, I would store another flag. When you get an offline message, you can then check the reason from being offline coming from mod_last storage.
I need to get the user email when I get document permissions. I have seen this problem here
value attribute for Permissions Resource not populated in responses
but in about service does not appear my email. I need it because I have a service account and my application need know the user email. I want to avoid call to profile service.
Is this possible? from where I can get the user email?
Thanks.
As you rightly say, you will have to make a call to the profile service. In some ways it is better like this, because it separates the concerns of the Drive API and the Profile API, and can use specific scoping to let the user know exactly what they are authorizing your app to do.
I'm building a site that offers functionality to users without requiring them to register. The idea is to send an email to the specified address containing a link with a token. That way the user would could this link anytime they want to make changes to the functionality.
While I realize that there is no way to truly secure such a concept, I'm looking for options to minimize the visibility of the token. In its current state, soon as the user clicks on the link it is added to their browser history, available to anyone who has access to the computer.
In most cases I would over come this with a simple form so that the token could be passed through with a POST request, but forms aren't really supported in emails.
So the question is, does anyone know of an alternative way to hide a token in such an email?
I'm sure you've thought of this, but you could send them a password and a link to a URL where they'd need to enter that password. If the emailed URL contained another password, it would be a smaller compromise to security than usual to make the user-entered password quite short, like a PIN number, say.
You could resend a new token every time the user wants to log in. Have them plop in their email address and send them a new token, while setting previous tokens to 'expired.' Or, if the server detects that an old link/token was used, it could automatically send a new one to the associated email address and ask the user to check their email for a new link.
That would require keeping track of old, expired tokens and the associated email addresses, but still requires no registration - just that a user check their mail every time they want to log in. You'd essentially be piggy backing on their email authentication.
It'd also be counter-intuitive for users.
This would turn the token into a cryptographic nonce, which is primarily used to prevent the replay attack you mentioned.
Another answer, perhaps more useful:
Some browsers (like Chrome) do not record 301 "Moved Permanently" redirects in the browser history. Firefox does, but there's a proposal to change that:
https://wiki.mozilla.org/Browser_History:Redirects
For example, in Chrome, if you navigate directly to
amazon.com
it will follow a 301 Redirect to
www.amazon.com
If you then check your browser history, it will only show
www.amazon.com
Thus, if your server returns a 301 redirect from the login link, the server could record the token, remove it from the redirect link, and the user's browser would only record the redirect link.
(this is my first time responding on stack overflow - let me know if my writing is unclear or if I'm missing other etiquette)