I have a bot in node.js and I'm wondering what logic I should use for a .tell function. The purpose of the function will be to give a message to users who are offline. So, if john was offline on freenode.net/#foo and I typed .tell john your mother was great last night, I want the bot to store this message and display it whenever john joins the channel.
If john is already in the channel, I want the bot to immediately just display the message.
I am already using mongodb as a database to store information, so I can probably store all my messages in there. Here's the logic I had in mind so far:
1. After user A types .tell john your mother was great, a listener will pickup the pattern /\.tell ([\w-]+) (.*)/ and store a variable for the message ( var msg, the user who posted the message ( var from ), and the name of the user to be messaged ( var to ). I will also have a global variable signifying the channel name and network of the server.
2. I'll store a row in mongodb such as:
to from message network channel delivered time
--------------------------------------------------------------------------------
john meder your mother was great freenode.net #foobar 0 (TS)
last night
3. Setup a listener for anyone joining a channel since the bot can live in multiple channels under one network, and detect if there any messages that are not delivered and if there are, attempt to match the to and network and channel to the stored messages, and if row(s) are found, display them.
This sounds ok, but can anyone review it and maybe offer advice? I'll be forced to have a listener listen for anyone entering any channel, right? There's no alternative to that?
This seems all fine. I don't see how you could not have a listener.
One thing I'd add is maybe a hash in the bot to keep track of who has pending messages. This way you won't be querying MongoDB every time someone joins a channel.
I.e.
messages = {};
messages['freenode.net'] = {};
messages['freenode.net']['john'] = 1;
Might be overkill, but if your monitoring a channel that has many JOINs, you might find yourself querying MongoDB a lot.
My two cents.
Christian
Related
I'm new to NATS and have read all the examples for:
https://nats.io/documentation/concepts/nats-messaging/
I'm in Microservciearchitecture where in microservice-Y (MSY) need to store some information published from other microservice-X (MSX) I have 2-10 instances of MSY so when changes are made in MSX and MSX-instance publishes event I want that only 1 instance of MSY should save information so not all of them save the same data.
I have read Request-Repy:
https://nats.io/documentation/concepts/nats-req-rep/
but there seems that all of instances receives message (and will handle it) even if it is point-to-point and reply is handled just for the one instance that is quickest to reply
Is this correct or have I missunderstood example?
If I only need that 1 instance of MSY should handle given message (store data in db) what can I do to acheve this?
Use queue groups. If you have multiple subscriptions on the same subject with the same queue group, only one of the members of the group will receive the message.
Check this out: https://nats.io/documentation/concepts/nats-queueing/
I have an Html page with a load of javascript that changes between views.
Some views require the person to be logged in, and consequently prompt for it.
How can I note the person has successfully logged in, using the javascript, that will not be a security issue, but will mean the person does not have to repeatedly log in for each view. I do not want to keep on going back to the server each time.
Edit:::
To explain more. Here are the problems I see.
Lets say I have the following in my javascript:
var isLoggedIn = true;
var userEmail = "myemail#mysite.com";
Anyone can hack my code to change these values and then get another person's info. That is not good. So instead of isLoggedIn do I need something like a hashed password stored in the javascript:
var userHashedPassword = "shfasjfhajshfalshfla";
But every where I read, they say you should not keep any password stuff in memory for any length of time.
So what variables do I keep and where? The user will be constantly flicking between non-user specific divs and user-based divs, and I do not want them to have to constantly log in each time.
****Edit 2:*****
This is what I am presently doing, but am not happy with.
There is a page/div with 3 radio buttons. Vacant games (does not require user information), My Game (requires knowledge of user and must be signed in), My Old Games (also requires logged in status).
When first going on the page it defaults on vacant games, and gets the info from the server, which does not require login.
In two variables in the javascript I have
var g_Email = "";
var g_PasswordEncrypted = "";
Note these are both 0 length strings.
If the user wants to view their games, they click the My Games radio button. The code checks to see if the g_Email and PasswordEncrypted are 0 length strings, if they are it goes to a div where they need to login.
When the user submits their loging info, it goes to the server, checks their details, and sends back an ok message, and all the info (My Games) that the user was requesting.
So if the login was a success, then
g_Email = "myemail#mysite.com";
g_PasswordEncrypted = "this is and encrypted version of the password";
If there is any failure in login, these two are instead set to "".
Then when the user navigates to any page that requires login, it checks to see if these two strings are filled. If they are, it will not go to a login page when you request information like My Games.
Instead it just sends the info in these strings to the server, along with the My Games request. The server still checks these Email and encrypted password are valid before sending back the info, but at the client side, the user has not had to repeatedly input this info each time.
If there is any failure in the server request, it just sends back an error message (I am using ajax) in the callback function, which knows to set the g_Email and g_PasswordEncrypted to "" if there is anything wrong. (In the latter case, the client side knows it has to re-request the login details because these two strings are "").
The thing I do not like is I am keeping the Encryted password on the person's client machine. If they walk away from their machine, someone can open up the debugger in something like chrome and extract these details, and then hack it into their machine some time later.
If javascript loads content for each view from the server then it is for server to know if a current session belongs to logged user or not. In case the user is not logged, the server responses with prompt to login, otherwise it sends content of the view.
If javascript bulds content for the views deriving it from the data that was already received from the server then it should use some variable keeping state of the user (logged/not_logged). And depending on that value javascript will either show a prompt to login or display required content of the view.
When I create an embedded document for signing, if the document times out after the 5 minutes allowed, how should I handle this? Just resend and basically create a new one? I've done this and it seems to duplicate envelopes... Is there a way to just renew the timeout, and re-direct the user to the same envelope? I've found similar posts but cant seem to find the exact answer to this... the goal of course avoiding a second envelope charge because they took longer than 5 minutes to sign the document. In creating a new envelope I'm sending the exact same document id, user etc.. but still seems to duplicate it on the back end.
The "short lived URL" that you generate from the API does expire, and it is only good for a single use. If you need another URL due to timeout or 'finish later', you can use the API to request another URL. You do not need to create another Envelope.
https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#Basic Scenarios/Embedded Signing.htm?Highlight=embedded
I am having a problem that has been reported here and elsewhere before: not being able to change the recurrence pattern on a master via EWS. First, I tried using the old proxy classes against E2010. I have also now tried using the 2.0 Managed API, to no avail. The error FWIW is "Set action is invalid for property". E.g. I want to change the recurrence end date, or the number of recurrences.
In an MSDN post from 2008, Dave Stirling mentions that only the organizer should be able to do this. This is a problem for me because my server application uses a single, full-access id to manage all of the room resource calendars in an enterprise. With this user I can delete appointments on any calendar, regardless of organizer, and I can certainly update a single instance of a recurring series, e.g. changing its start time. I don't understand why manipulating the recurrence pattern would be prohibited because I'm not the organizer while manipulating an instance's spot on the calendar, or deleting the entire series would not be.
I have also tried using impersonation, so that I am (I think) impersonating the Room resource itself, in which case, even though I am not the organizer, I feel I must be the owner of the appointment, and hence entitled to do whatever the heck I want to it. I guess Exchange feels differently. Managed API code below, FWIW.
TIA,
Paul
var Svc = new ExchangeService(ExchangeVersion.Exchange2010, TimeZoneInfo.Local);
Svc.CookieContainer = new CookieContainer();
Svc.Credentials = new WebCredentials(m_SvcUser, m_SvcPswd);
Svc.EnableScpLookup = false;
Svc.ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress, m_RoomMB);
Svc.AutodiscoverUrl(m_RoomMB, RedirectionCallback);
var Master = Appointment.Bind(Svc, new ItemId(args[0]), m_Props);
if (Master.Recurrence.NumberOfOccurrences != null)
Master.Recurrence.NumberOfOccurrences--;
else
Master.Recurrence.EndDate = DateTime.Now;
Master.Update(ConflictResolutionMode.AlwaysOverwrite, SendInvitationsOrCancellationsMode.SendToNone);
To close this out, I will report that I opened this question as a support issue after getting no responses here or on MSDN. The net of it is this: Exchange does not permit an attendee (in this case a conference room I am impersonating in EWS) to change the recurrence "blob." This is by design. The only user who can do so is the organizer. I'm not sure this really makes complete sense to me, but I don't have much say in the matter, now do I?
Thanks for your reply for my question: Is this a bug of Box API v2 when getting events
This is a new problem related to this. The problem is that I cannot reliably use the next_stream_position I got from previous calls to track events.
Given this scenario:
Given the following two GET HTTP queries:
1. GET https://api.box.com/2.0/events?stream_position=1336039062458
This one returns the JSON file which contains one file entry of myfile.pdf and the next stream position = 1336039062934
2. GET https://api.box.com/2.0/events?stream_position=1336039062934
This call uses the stream position I got from the first call. However, it returns the JSON contains the exactly same file entry of myfile.pdf with the first call.
I think if the first call gives a stream position, it should be used as a mark for that exact time (say: TIme A). If I use that stream position in subsequent queries, no events before "Time A" should be returned.
Is this a bug? Or did I use the API in the wrong way?
Many thanks.
Box’s /events endpoint is focused on delivering to you a highly reliable list of all the events relevant to your Box account. Events are registered against a time-sequenced list we call the stream_position. When you hit the /events API and pass in a stream_position we respond to you with the events that happened slightly before that stream position, up to the current stream_position, or the chunk_size, whichever is lesser. Due to timing lag and our preference to make sure you don’t miss some event, you may receive duplicate events when you call the /events API. You may also receive events that look like they are ‘before’ events that you’ve already received. Our philosophy is that it is better for you to know what has happened, than to be in the dark and miss something important.
Box events currently give you a window roughly 5 seconds into the past, so that you don't miss some event.
We have considered just delaying the events we send you by about 5 seconds and de-duplicating the events on our side, but at this point we've turned the dial more towards real-time. Let us know if you'd prefer a fully de-duped stream, that was slower.
For now, (in beta) if you write your client to check for duplicate events, and discard them, that will be best. We are about to add an event_id to the payload so you can de-duplicate on that. Until then, you'll have to look at a bunch of fields, depending on the event type... It's probably more challenging that it is worth.
In order to help you be able to figure out if an event is a duplicate, we have now added to each event an event_id that will be unique. It is our intention that the event_id will allow you to de-duplicate the responses you receive from subsequent GET /events calls.
You can see this reflected in the updated documentation here, including example payloads.