Is there any way to get the Channel ID on the server or transmit it inside a RequestFactory call?
Situation:
User starts the application, a channel is being opened.
User persists an entity with RequestFactory (requests.persist().using(...).fire(...)).
The persist() method on the server pings all connected clients to tell them that the entity has been updated.
But the user that made the initial change doesn't have to be pinged. Is there a way to find out which client made the change? It's not enough to know the user, because one user may have opened several windows (channels).
Honestly I haven't used Channel API yet but according to documentation each client is treated as separate user. So the solution lies beyond GAE API and I think you have two options:
Create logical User ID on the client that will be mapped to possibly multiple channels. That way you'll know what channels to skip.
Ping all channels anyway but send numeric Version of newly persisted entity. Then client will compare received version with what it has and if it's higher it means it needs to call findModel(id) again.
Related
I have a service account that should represent the flow for multiple mail-accounts. The flow is started whenever a mail arrives in a mailbox, then a confirmation should be sent after that. Let's assume I have 100 different mail-accounts in the company and the flow should be triggered for all of them, this should be bundled (dynamically) in the service account. How can this be done?
With dynamically I mean not "hardcoded" mail-accounts in the trigger (because they are changing a lot).
I never have used logic apps, but are they a better solution for that?
I have 2 ways for this
WAY-1
You can either use a Distributed list mail where all the members in your team are the members and trigger an email.
WAY-2
I have created a list adding the person column and adding the members to the list in SharePoint and sent mails using that column. Here is the Screenshot of the flow that I used
I have the following code in my angular app declaration - an API key for Facebook (to implement Share button):
.run(function($FB){
$FB.init('9xxxxxxxxxxxx94');
})
So i know the general answer to this - 'API keys should be kept on the server side', however I don't see how i actually implement this.
The share call-method is made on the front end, so even if my server kept the API key and sent it, surely it's still visible on the front end, else how would the share button work?
So my question, how do I hide that Facebook API Key?
Thanks.
Requesting the key
The first thing that happens is that the client will request a key. This will only happen on certain pages like the sign up and log in pages. The idea here is that we want to make sure that only users browsing with a known client (in this case the official website or core client as it’s called) are allowed to take actions like creating or authenticating a user.
So when the client app requests the login page the server generates a unique token based on information sent in the request. The information used is always something the server knows, something the client knows, and something both know. So for example the server can generate a unique key based on User agent + current time + secret key. The server generates a hash based on this information and then stores a cookie containing only the hash on the client machine.
Setting permissions
At this point our key really isn’t a key anymore. It has been transformed into an access token. The server should then take this access token and store it for later retrieval. You can put the key in a database but since data of this type needs to be retrieved often I would suggest using a key-value store like Redis to cut down on database reads/writes and boost performance.
When you store the token you should also store a separate piece of data to indicate what permissions are associated with the token. In this case our token is acting only as a way to register and authenticate users so we store it next to a value that indicates who the token belongs to (the app’s web UI) and what permissions it has (limited to create and authenticate users). We treat it just like we would any other API client that way we can capture stats and control how it is used.
Authorizing a request
When the client then makes the POST request to create a new user or log in the server will check to see if the client sent an identifying cookie along with the request. If not, we reject the request. If it does send the cookie, the server should once again generate the hash using the values used previously (these values are either already known or sent with the request anyway so we’re not really taxing the server much) compare it to the cookie being sent to us, and if the values match allow the request to proceed.
Sources - Securing API Keys
OR
Simply send a request to your Server and let him handle your request with the hidden API-key and just return the result of your request to your front-end.
Since Parse is shutting down, we are currently using Firebase to support basic data storage and real-time messaging. However, in order to implement a key feature in our app, we need to run some code on a server. The following is what we are trying to accomplish:
We allow users to upload key words to Firebase, then we want to send notifications to them if any new posts that contain these key words were uploaded by other users. For example, userA wants to know if anyone posted information related to chemistry, so userA enters key words "chemistry" and "science" in our app which get stored in Firebase, userB posted an article called "chemistry rocks!" which contains the key word "chemistry", userA will then receive a notification immediately about this post.
We have a couple of solutions in mind, but we are not sure which way to go and how to properly implement these solutions.
1 - Build a server that listens to Firebase changes and also supports sending notifications to individual users. However, to host and maintain a server just to run a search algorithm is just too much work for this simple task.
2 - Store the key words in another database that somehow can send notifications according to the search result. This would be faster because we wouldn't have to connect Firebase server to our own server, but again we would still have to host and maintain a separate server.
I have looked into Google App Engine, their push/pull queue feature sounds like something we want, but does GAE support notifications? And also how can we hook it up with Firebase? We also came across Firebase+Batch to send notifications, but I don't think Batch supports cloud computation.
Has anyone run into this problem? Any solutions?
What is Synchronizing client with gmail ? Can anybody give a detailed explanation, because i want to have a better understanding over this concept.
For example, if your client keeps any local cache of the Gmail mailbox data like the Message.Id and labels, or headers, or the entire email. Then in order to update your client you're synchronizing it with Gmail--pulling new updates down to your client. In cases of clients designed for offline use, then synchronizing may also mean pushing local updates back up to the server (e.g. label updates made by client while "offline" that get applied at some later point). That's the general definition of synchronizing.
For the Gmail API specific case, Gmail has a backend mailbox-wide history Id. Any change that affects that account in any way gets a history identifier and most (but not all) history changes affect the state of email messages. Like adding a new message, changing the labels on a message, or deleting a message. Clients of the Gmail API can poll the history Id and find out what's changed since the last time they synchronized and pull down updates to maintain their sync.
Going by the GAE docs for the Channel API,
Only one client at a time can connect to a channel using a given
Client ID, so an application cannot use a Client ID for fan-out. In
other words, it's not possible to create a central Client ID for
connections to multiple clients.
seems contradictory to
Treat the token returned by create_channel() as a secret. If a
malicious application gains access to the token, it could listen to
messages sent along the channel you are using.
How can they both be true? But more importantly, I'm planning to create one channel for each logged in user in my app. Now if the user opens up a new tab with the app, can I use the same token again? The alternative of creating one channel per tab the user has open sounds quite odd, not to mention expensive.
If you open more than one socket on a channel with the same token, results are undefined. Both sockets may receive messages, or neither, or just one. (actually we technically support two connections reliably, for cases where the user refreshes a page)
If you want to support multiple connections by the same user (in different tabs or different computers or whatever), you'll need to create a clientids per tab/browser instance/computer etc.