How to know if a user is currently logged-in in your Google App Engine application?
The application allow its users to browse other users' profile. If the viewed profile is also using or logged-in in the application, i want a notification that the viewed profile is online.
How to achieve this requirements?
If you are managing user profiles, you know when a user logs in. At the end of the login process, just save the user's log-in information in the memcache somehow.
You will later be able to check if a user is logged-in just by searching for him in your memcache.
This way is easy to catch and track the connection events, but you also have to react when a user disconnects, to have your list up to date. To achieve this, you can use a Channel. See the google documentation.
You could, as Gaël suggests, use the Channel API to track this, but it's probably overkill. If you wanted to go that route, just listen for the connected & disconnected messages, and update a field in the db that indicates that the user is signed in.
A less expensive route might be to just update a field in your user's record that's something like "last time this user requested a page." If it's been more than n minutes since the last time the user requested a page, assume they're signed out. Indeed, you could even do this in memcache with a map from userid to last access time.
It comes down to what you want to do with the "signed in" information: if you just want to give a general sense of whether a user's around, or how many users are online, using the datastore or memcache solution is probably good. On the other hand, if you want to reflect the user's presence so they can respond to eg. IMs, then you'll probably want the Channel API anyway so you can immediately deliver messages to them.
Related
I am new to Salesforce, but am an experienced developer. I am provided a link to a Salesforce report, which mostly has the right filters (query). I would like to use an REST API to pull that information as CSV or JSON so that I can do further processing on it.
Here are my questions:
Do I need special permissions to make API calls? What are they?
Do I need to create an "app" with client-key & secret? Does my admin need to grant me permission for this too?
There are a lot of REST APIs from Salesforce, which one do I need to get the info from the report? Analytics?
How do I authenticate in code?
You'd have to work with the System Administrator on the security pieces. Anybody who knows how the company works, can all users see everything, is there Single Sign-On in place, how likely is the report to change...
You will need an user account to pull the data. You need to decide if it'll be some "system account" (you know username and password and have them stored in your app) or can it run for any user in this org. It might not matter much but reports are "fun". If there will be data visibility issues 6 months from now, you'll be asked to make sure the report shows only French data to French users etc... you can make it in report filters or have multiple reports - or you can just use current users access and then it's the sysadmin that has to set the sharing rules right. (would you ever think about packaging what you did and reusing in another SF instance? Making a mobile app out of it? Things like that, they may sound stupid now but will help you decide on best path)
The user (whether it'll be system account or human) needs Profile permissions like "API Enabled" + whatever else you'd need normally ("Run Reports" etc). If you're leaning towards doing it with system user - you might want to look at Password Policies and maybe set password to Never Expires. Now this is bit dangerous so there would be other things you might want to read up about: "API only user" (can't login to website), maybe even locking down the account so it can login only from certain IP ranges or at certain times when the job's supposed to be scheduled...
Connected App and OAUth2 stuff - it's a good idea to create one, yes. Technically you don't have to, you could use SOAP API to call login, get session id... But it's bit weak, OAuth2 would give you more control over security. If you have sandboxes - there's little-known trick. You can make connected app in production (or even totally unrelated Developer Edition) and use client id & secret from it to login to sandboxes. If you create app in sandbox and you refresh it - keys stop working.
(back to security piece - in connected app you can let any user allow/deny access or sysadmin would allow only say these 3 users to connect, "pre-authorize". Could be handy)
Login - there are few REST API ways to login. Depends on your decision. if you have 1 dedicated user you'll probably go with "web server flow". I've added example https://stackoverflow.com/a/56034159/313628 if you don't have a ready SF connection library in your programming language.
If you'll let users login with their own credentials there will be typical OAuth "dance" of going to the target page (Google login, LinkedIn, Twitter...) and back to your app on success. This even works if client has Single Sign-On enabled. Or you could let people type in their username and pass into your app but that's not a great solution.
Pull the actual report already
Once you have session id. Official way would be to use Reporting API, for example https://developer.salesforce.com/docs/atlas.en-us.api_analytics.meta/api_analytics/sforce_analytics_rest_api_get_reportdata.htm
A quick & dirty and officially not supported thing is to mimic what happens when user clicks the report export in UI. Craft a GET request with right cookie and you're golden. See https://stackoverflow.com/a/57745683/313628. No idea if this will work if you went with dedicated account and "API access only" permission.
I am building a react site where users can purchase a "day", "weekly" or "monthly" pass for the content on the page. I only want to allow them access for a day if they purchase a day pass. Same for weekly and monthly. I am using JWT to keep users logged in. I have no idea how to create the functionality to verify if they should still have access or not. Would love some help. I am also using redux if that helps.
You need to start thinking about Authentication and Authorization separately. Your JWTs are (hopefully) performing the Authentication duty. The "limited access" you're asking about are the concern of Authorization. In other words: now that you know who this user is, what are they allowed to do?
You need to map your JWTs to some form of internal user id, and then determine if they can or cannot access the requested resource/endpoint/etc.
For example, you might allow all users to GET from /jobs to view the listing of job postings, but if they try to POST to /apply for a job, you verify that they are a "premium" user, with time remaining on their paid subscription.
I have an application deployed on GAE. It allows users to register for an account, and I use the google user id as the primary key to link to their account.
I have a registration link that should be visible if either the user has not been authenticated by google and/or they do not have an account on my site.
What I am trying to figure out is what is the best way to figure out if the user has an account on my site as they go from page to page. I have an authentication filter that is triggered on every page, and the filter looks at their google id (if they are logged in), goes off and determines if the user has an account on my site, and sets a request parameter, that I use in the jsp to determine whether or not to show the registration link.
It seems wasteful to do that every time, so I refactored it and had the authentication filter store the Key object tied to their user account on my site in a Session. If the key attribute is not null, I take that to mean that the user is registered on my site.
Does that seem logical, or are there better approaches? The complexity to me comes from the fact that the user may be logged in with google, but that doesn't necessarily mean they have an account on my site.
My question
When it comes to storing authentication data, you have two options :
Store the data in session
Store the data on client side, in a cookie typically
Storing the data in session is a perfectly valid mechanism, and that's actually the most common.
However, managing a session is costly (you need to store it). In App Engine's case the sessions are stored in the Datastore, with probably some caching. So it's still a call to the datastore.
That should be totally acceptable, however if it turns out managing a session really decreases you app's performance, you can always store the data in an encrypted cookie. That way the information is provided by the browser every time it sends an HTTP request. Note that it means you must get encryption right and that HTTP requests will be slightly bigger (the size of the encrypted data).
So in the end it's a tradeoff. I would recommend sticking to sessions unless you experience performance issues. The advantage of sessions (compared to your fist approach) is that if you ever want to store additional data, you will have less code to add.
How can i persist user details in angularjs unless user logs out of the system?
My header is using a variable called user, so when the user logs in successfully, i set the user attributes from REST response.Once , user is set then using ng:show and $scope.watch i change parts of the header and show welcome 'username'.
The issue comes when user again refreshes the page, in that case User is reset and user sees the landing page header.How can i correct it?How can i persist the User value unless user logs out of the system?Should i set user in rootScope or is there any other better way to handle this?
This is an open-ended question and to really answer it, I'd need to know what your back end looks like and what your security requirements are.
I can see a two ways forward:
(1) If can rely on and trust cookies for security, you could just log the user in with data from cookies just like you log them in via the REST response. The cool thing about this is that, to the user, it would be instantaneous (the next option won't be).
(2) Have a separate controller that handles the header that will always make a request to the server for user data (logged in or not). SEN does something like this (and it drives me crazy btw). I don't know if you have a SEN account, but if you do, you could log in/out and try it out. You'll see that when you hit the page initially, you get a loading screen, but even after that loads, the header even has a little "Signing in..." loading widget itself.
You can use the local storage (a key-value pair HTML5 storage) to store the information and retrieve it on page load. There is a very simple library for this, if you don't want to write javascript yourself, called Lawnchair. Otherwise google for html5 local storage tutorials.
So I'm writing a mobile app and have reached a point where I need to allow users to register a username. I'm doing this by asking for an email address, username and password.
Typically, it's been normal to set this sort of thing up on the web by having the user confirm his email address by clicking on a link sent to his inbox.
Needless to say, on a mobile app this is a bit clunky as the user will be redirected out of your app and into his browser.
So I had a look at how other mobile apps are doing it (WP7) and was surprised to see that DropBox and Evernote both allow you to sign up without confirming your email address. The end result of this is that I was able to sign up with completely bogus email addresses and/or valid email addresses that don't belong to me.
I assume this is done on purpose.
Your thoughts?
I came across the same issue when writing a social networking style app. I chose to have the user create a username and then provide and email and password. I do not verify the email address and I've never attempted to send any email to them (yet).
What I would suggest would be alternate ways to validate a users email address. My app allows users to do Facebook Connect. All they have to do is log into Facebook, and the app talks to Facebook to confirm that they are using a valid email address. No need to verify it with a URL in an email.
I believe Twitter has a similar service and there may even be a few others that provide an API.
I've also discovered that a lot of people just want to tinker around in the app and not create an account at all. It's definitely a balancing act
I'd say it depends on your app and how important it is to ensure users have valid email addresses. In an app I'm creating now, we want to discourage users from signing up with multiple bogus accounts (because our system could be gamed that way) so we're not allowing users to log in until their email address if verified. On other sites however, it might not be such a big deal so why bother users with that extra step?
As for a mobile device, I don't see why you can't still send a verification email that sends them to your website to verify their email address. There are plenty of mobile apps that also have a website users can log into to manage their account.
Another option is have multiple "states" for users. Before they validate their email, they are in a "pending" state. Once they click it, they're in an "active" state. If you store the createDate for the user, you can periodically remove pending users older than 1 week (or however long).
The bonus is that you can easily add more states, such as suspended or deleted.
Personally, I wasn't too happy for users to create accounts with any old email address.
I think a few decent options are:
send a confirmation email with a link that uses a Custom Url Schema to redirect back to the app (although this is only good if they use the link on the same device)
send a short PIN in the email for them to enter back in the app.
send a confirmation email with a web link, have your server confirm the valid email/token, and have your app check the account status either periodically or with some sort of realtime tech like SignalR or Firebase.
I prefer the last one, although hardest to implement. A user might well have their phone in their hand and their laptop next to them, register in the app and try to click the link in the email that just showed up on their laptop. I like the idea of the app then just "knowing" that they've validated.
Do you have a web server? Write a web service that does the validation for you on the server side, and sends back the result.
Either you can use some platform, such as Facebook connect as #Brian replied above, or you may give users a reasonable timeframe to verify, for example, a few days or even a week. After that, the account gets removed.
You can even have your app issue notifications to remind the user to verify his account (such as every day, or on the last date of the verification.
Don't ask for email confirmation on mobile and allow the user to use the service. When the user is using a PC, then ask the user to confirm his email.
I won't defend my recommendation because most of the solutions here are valid. There isn't one correct way. You asked for ideas and here's one.
A good strategy is to allow people to use as much of your app as possible given the amount of data they've provided.
For example, in the case of a newsreader you might let someone browse your app without registering, then require an account for offline syncing, and a verified email for alerts. Always give people a good reason to take the next step, and build engagement first, then people will forgive you pestering them later.