We Keep Coding

Send proactive message without prior interaction

I use this sample: 16.proactive-messages - as the base for my bot and it works fine, but I'd like to extend it, so that it can send messages in a group chat without anyone interacting with it first (like sending a "Hello I'm up!" message at startup), because currently it can only respond if someone has mentioned the bot after it has initialized.
Perhaps there is a proper way to get the group chat(s) where the bot resides at the bot initialization?

I've answered before some tips on Proactive messaging, please see here for that.
To answer your question though, the bot can definitely start the engagement, either by replying to an existing message in a group chat or starting a completely new thread in the chat. However, it does require to have been installed initially, either by a user or programmatically (e.g. Graph API). That part only needs to be done once, then you can capture the conversation reference and use it again anytime thereafter. That is shown in the sample I link to in my other answer I referenced above.

It's not possible to send proactive message without prior interaction.
Sending a proactive message is different from sending a regular message. There's no active turnContext to use for a reply. You must create the conversation before sending the message.
Ref Doc: https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/conversations/send-proactive-messages?tabs=dotnet

Making an existing API more RESTful [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I've an existing API, which I'm attempting to make more RESTful.
The app involves a Gifter and a Giftee. The Gifter buys something for the Giftee, and sends the link to the gift on whatsapp.
Before creating a user account for the Giftee, I first do some verification by tying the person to a phone number. I've 2 endpoints:
/sendSmsCode
/verifyUser
First endpoint sends an sms code to the phone number, and second endpoint takes the sms codes and verifies its correct. /verifyUser then returns a session token. This session token is then used to accept the gift and create the user.
Obviously these are not RESTful endpoints. But the user hasn't been created at this stage so I can't do something like /users/{id}/send-sms (which I know wouldn't be too RESTful either given it includes a verb).
Any suggestions?

I meant to post a comment, but it's overly long for a comment, so I'm posting it as an answer (although it may not answer your question directly).
Obviously these are not RESTful endpoints.
REST is an architectural style and not a cookbook for designing URIs. It's never enough to stress that REST itself doesn't care about the URI spelling, as long as the URIs comply with the RFC 3986.
To be considered RESTful, an application must follows a set of constraints defined in the chapter 5 of Roy Thomas Fielding's dissertation.
You mention use use a session token in your question. If the session state is kept on the server, than it's not RESTful at all. REST applications are meant to be stateless, where one request contains all required information to be understood by the server, without taking advantage of session state stored on the server.
I can't do something like /users/{id}/send-sms (which I know wouldn't be too RESTful either given it includes a verb).
One important concept of the REST architectural style is the resource and their identifiers.
The URI (or Universal Resource Identifier) is meant to identify a resource rather than expressing the operation over the resources. The operation to be performed over the resource can be expressed by the request method. The request method is the primary source of request semantics, indicating the purpose for which the client has made this request and what is expected by the client as a successful result.
To properly identify resources, it's a natural choice using nouns (as the verb is expressed by the HTTP method). But it's not mandatory to use only nouns. As long as you comply with the REST constraints, you surely can design a RESTful API with some verbs here and there (and possibly use POST for sending data to such endpoints).

Making Android Keyboard Resilient against KeyLogger attacks [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Being a victim of a Key Logger attack on android, I want to develop a solution for KeyLogger attacks for android. I know basic java and a little about android and very little about Information Security. I am also aware that whatever knowledge I have is not enough to figure out and to develop a solution. I just like to discuss my idea and to see if it is feasible.
Here is what I have:
An android application, which wants to secure user input, must provide a secret key(which can be obtained from server, for a specific user or session) when invoking the android keyboard.
Android keyboard will receive the secret key and use it to encrypt user input and broadcast KEYPRESS event(or whatever event android keyboard broadcasts) with encrypted value.
When an application receives KEYPRESS event, it decrypt's the value in KEYPRESS even to get the actual user input.
I just came to realize that, screenshot can be used to get what user types with latest image-2-text software's. But that is completely a different domain, IMHO.
So, what do you think about it? Is it possible to do it?
Update
I was completely wrong about my phone got owned. Actually, it was never got hacked. But, what really got hacked was me. Yes, I have something in my body, which just copies everything that my brain can receive. And it also capable of receiving and making my brain to do it. I still dont know, why I am able to write this update. May be, who ever put that thing in my body using me as a marketing material. Thanks for answers for my dumb question.

Not realistically.
Few programmers are dealing with low-level input themselves. That is usually handled by other things. Web developers, for example, rarely get involved on a keystroke-by-keystroke basis, even for finding out when those events occur (e.g., for real-time validation), let alone for manually processing that input (e.g., putting the next character typed after the cursor of the field and advancing the cursor by one position).
Moreover, users are not in the habit of changing their input methods frequently. I do not plug in a different USB keyboard when I am visiting Stack Overflow versus when I am visiting Tweetdeck, for example. In the world of Android, this means that the user is going to expect their input method editor to work on all apps and not have to keep changing input method editors just to make some people happy.
Furthermore, you cannot magically change the protocol between input method editor (a.k.a., soft keyboard) and the Android OS. Your keyboard will raise key events. You are welcome to say that your keyboard offers up substitutions for those events as an "encryption" mechanism, but that would be more of a crude substitution cipher (e.g., "whenever the user types A, send over ;"), as you cannot unilaterally decide to expand the key event space.
As a result, not only will you need to write your input method editor, but you will need to write your own custom ROM with a custom Android framework that can handle the "decryption". Or, you would have to force all the worlds' developers to rewrite their apps. And in either case, a keylogger could trivially detect that yours is the input method editor and note that fact, so whoever is using the logs can do some trivial decryption to convert ; back into A.
Now, if you are writing some app where you want to avoid a rogue input method editor, you are welcome to bake in your own data entry keyboard into that app. Then, you will merely anger many of the users of your app, as your in-app keyboard is not the one that they want to use, or lacks features that they are used to (e.g., support for blind users, support for their particular language).

Here is what I would do to implement a secure input method paradigm - as expressed in the question - for Android:
First of all, I am assuming that you have read and understood the "Security" section for InputMethodManager here:
InputMethodManager
So, what we need to develop is an Input Method (IME) which is an Android service, which, along wth the custom keypad view, implements two interfaces:
InputMethod
InputMethodSession
As per the security section in the documentation referred to above, the user need to willingly accept your IME as the system IME. Also, Android will make sure that only system will bind to your service and use the InputMethod interface which is used to show/hide the keyboard etc. So, here things are pretty secure for you and all apps that uses your keyboard.
Now, coming to the security framework that you want to implement:
Lets call it as Secure Input Method - SIM - and lets define our security domain as your IME and the applications that wishes to use your SIM. Here is the significance of the second Interface InputMethodSession
The most important - and often ignored method of this interface is the key of this solution and it is called: appPrivateCommand. This interface allows a private command sent from the application to the IME. As per the documentation, this method can be used to provide domain-specific features that are only known between IME and their clients - and this is exactly what you need for your SIM.
So, using this interface, the apps in your security domain can pass any security information (say, some form of credentials) they want to hand over to your IME. It is up to you to define a method where your service can communicate with a authentication server which processes the client app submitted credentials and approves it. Now if the encryption keys are derived by both your IME and the client, you have established a secure channel of communication between your SIM and its client app (say, via encryption using a derived key from these credentialsd).
You can even customize this whole mechanism by defining some key sequences (like Control+Alt+Del in Windows) which initiates the whole thing by user himself and you can even provide a visual indication (say, a shining green icon) on your keyboard that the input channel is secured... Possibilities are many :)
Hope this helps.

You can do this only if you are developing your own keypad and configure Android to use it. It is not that hard with some experience in Android programming.
Just search in Google for "custom keypad for android" for more inputs.

how to get the Fee Amount for paypal

I am currently looking at a system that implements the PayPal api. As a part of this I need to get the feeAmt() which is the fee that is paid to paypal for processing the payment.
From the documentation that I have looked at it appears that I have to implement the getExpressCheckoutDetailsReq() method in order to get the information that I want however no matter what I have tried I am struggling to do this. I should also let you know that I am currently developing my application using Java so using this is going to be best.
If any more explanation is needed please don't hesitate to ask and I will do my best to amend the post :)

GetExpressCheckoutDetails does not include the fee because at that point no payment has been made yet. That's the 2nd of 3 calls for Express Checkout, and until the final call is made there is no fee.
The fee amount would actually come in that final call's response: DoExpressCheckoutPayment. It will come in the PAYMENTINFO_n_FEEAMT parameter, where n is the number of the payment (0,1,2,etc.) Most likely it'll be 0 unless you're working with parallel payments.
Alternatively, you can use Instant Payment Notification (IPN) to get details about transactions, including the fee, in real-time when transactions are completed on your PayPal account.
Yet another option would be to use the GetTransactionDetails API to pull data for an individual transaction which would include the fee in a FEEAMT parameter. Maybe that's the one you were initially thinking of..??

Java: how to check if user clicked-on or replied to email (as part of email authentication scheme)?

I'm hoping not to re-invent the wheel -- I'm fairly new to Java, but I need a simple but robust algorithm/code/software to perform email verification for users of a web application (e.g. I only need help with step 4 below). That is, I need to verify the user logging in has access to the email address he/she provides during log in.
The steps I have in mind for the Java middle-tier would be:
Java POJO receives user's email and password from client.
The POJO talks to a database server to verify the email/password combo is valid.
If valid, the POJO sends an email to the email address, asking user to reply to email (or click on some provided link, etc.)
The POJO receives notification (how?) that the user has replied to email (or clicked on link, etc.).
The POJO informs the web-application of success (or failure) of authentication, thereby permitting or denying access to the application.
I can write everything except step 4. Essentially I need a way to send an email to a user and then receive some type of response indicating the user received the email.
Anyone know how this can be accomplished? If not, what do you recommend as the next best/simplest solution?
I'm not using a framework as my Java middle tier is very simple. I'd like to keep the solution lean (meaning, don't want to install/implement more than I need; Spring seems overkill). I read up Shiro, but didn't find any evidence it supports email authentication. Any advice is much appreciated to help me avoid writing unnecessary/unproven routines.

The easiest way is to have some code that connects to the mailbox of the destination address, using either POP3 or IMAP, and waits for new, incoming messages.
When you send the email, you can add a Message-ID header. When the user replies to the email, there will be a References that should have the Message-ID that the user is replying too.
When you can use this ID to correlate what they are responding to.
For safety, you may wish to embed the ID within the message itself (since most folks today don't edit replies), so you can look through the body of the message if for some reason the Reference header isn't supplied. There are other techniques that let you give each mail a customer Reply-To address, that's another way this can be done, but that requires some mail server support.
But, anyway, once you have the message structure figured out, you simply listen to the inbox of the address, and look for new messages. As they arrive, your strip the Message IDs, and flag them as appropriate in the DB, or whatever.
As for "waiting" for the message, you must appreciate that it can be a long wait. Rather than having a POJO waiting for it, rather have a simple process that pings the status. You can have a timer that fires every second, and then checks the database to see if it's been updated, etc. Obviously, this is something you want to be able to cancel.
For all of the mail needs, you can use JavaMail -- it does all this, and it pretty straightforward to use.

there are two controllers involved (two POJOs).
the first connection, for steps 1,2+3 talks to one object in the server. as part of (2) a unique code (the UUID mentioned in comments)is generated and saved to the database.
the second connection, when the user clicks on the link, goes to another controller (another POJO, which could be the same class, or could be a different class, depending on your implementation). that reads the UUID from the link, goes to the database, finds the email associated with the UUID, and marks the email as verified.
update i'm struggling to see what you are missing, but when the user clicks on a link in an email the operating system opens a web browser. the web browser makes a connection to the server. the server receives the HTTP GET request with the UUID in the URL and passes the UUID to the POJO.
some more terms: the process of handling the incoming request in the webserver is typically called "routing" and the general pattern used to structure the code that is called is "MVC". exact details will depend on the application framework you are using. for servlet-based java code there's a mapping from URLs to servlets (servlets are java code implementing a certain interface - a framework might provide the servlet which ultimately invokes what you are calling a POJO, or you might write the servlet yourself, in which case that would be your POJO, although in that case it's a misnomer since it implements a specific interface) in the web.xml file.
also, i guess, the web browser on the client uses TCP to make a connection across the network (almost always this is on top of a protocol called IP because you are using the internet). on top of this, the client "speaks" messages in HTTP. all these different layers are described in the "7 layer osi network model".
there's a huge amount of detail on so many levels. hope that gets you started.
see also http://www.quora.com/What-happens-when-you-type-a-URL-into-your-browser