I am using Zend Framework 2 with ApiGility.
I have the following scenario:
A website where users login and manage their accounts: www.website.com
Apps hosted separately: app.website.com (that users want to use)
The sub-domain is not necessarily hosted on the same environment or even in the same datacenter.
Now, if a user accesses an app directly, I need to check if they are logged into the main website so that I can grab user related information needed by the apps.
I am not 100% sure of the best way to go about this.
For the App to work I need the following:
A 32 bit code (a unique identifier that the app uses in place of private information)
Account balance (to make payments for app services)
To get the 32 Bit code, I was thinking of setting up the following:
www.website.com/api/is/logged/in
Which would return the 32 bit code I need, if the user was logged in.
To get the account balance I would then use the code:
www.website.com/api[:/code]/get/account/balance
If the user was not logged in then the app would provide a form for the user to login which would be sent to: www.website.com/api/logg/user/in
If the users account balance needed to be topped up, then I would likely open an iframe to a payment page on the www.website.com for the user to make a secure payment.
This is kind of new territory to me so not 100% sure of the direction I should be taking or best practices...
Any advice appreciated.
thanks!
It sounds like you're looking to implement Single Sign-On (SSO) between a number of completely distinct applications. I would check out SimpleSAMLphp...it will do everything you need:
https://simplesamlphp.org/
https://github.com/simplesamlphp/simplesamlphp
Related
I want to use Shopify for our commerce solution but to build out a custom admin/user settings system. The key hurdle I'm dealing with is users and authentication. Let's assume my site is a.com and my admin system is my.a.com on a different host. I want the user to be able to log in to both the Shopify site and their custom admin/user page using the same username and password (effectively SSO but without a third-party service).
Constraints:
I don't want to build a custom application as I foresee us ultimately going fully custom at some point down the road
Just in case someone asks, yes the admin/user settings page is complex/unique enough that it warrants a custom solution to provide a good user experience.
Possible Solution 1
Have accounts created on the custom admin site and use the Create Customer API to keep the two databases in sync.
Questions:
How do I handle the email validation coming from Shopify (the customer should be oblivious to Shopify as it's an implementation detail)
Possible Solution 2
Have all accounts created via Shopify and the admin site and create an associated on on the admin site.
Questions:
How do I handle authentication for a specific user across origins. The only OAuth scenarios I seem to be able to track down are at the app level not per user.
I greatly appreciate any insights you all may have. Thank you.
I wrote an app script which provides a web UI for data entry into a team calendar. I published it using G-Suite super admin account and added it as Trusted App under Security/API Permissions. "Trust domain owned apps" is checked under "Internal App Settings".
When a G-Suite user in our organization tries to access the app, he sees
"The developer of ShiftSchedulingApp, admin#_our_organization_.org, needs your permission to access your data on Google."
Those brave enough to click "Review Permissions" are taken to the next message:
"ShiftSchedulingApp wants to access your Google Account. See, edit, share, and permanently delete all the calendars you can access using Google Calendar"
Of course nobody wants to risk losing all the calendars on their Google Account and this is where it ends.
How do I get rid of this misleading message? It's not Google account, it's their organization account on G-Suite. It's not all their calendars, it's the shared team calendar only. It's adding data, not permanently deleting calendars. It's published by their administrator in their G-Suite, not an unknown 3rd party.
I spent days trying to make this message go away but no luck. App must be executed as an accessing user and not as publishing user because their user ID determines what shifts they can fill on a calendar.
I'd appreciate any hints pointing me the right direction.
I experimented with variations of the two-app approach as suggested.
The app which provides the UI needs to read the calendar to display available shifts - so I can't get away from the user authorization prompt.
Another variation I tried was having one app do everything and run as me, and another do nothing but return Session.getActiveUser(). I tried calling the 2nd one from the 1st one on the client side via XMLHttpRequest. It would be ideal for my needs - but I hit CORS error as apps URL is script.google.com but it actually gets redirected to script.googleusercontent.com. There doesn't seem to be a way to set CORS in Google App Script.
Although I was not able to find a way to avoid prompting users for authorization when executing the app as accessing user, it turns out my reasons for doing that were based on a false premise.
I chose to publish app as accessing user because I thought that's the only way to get accessing user Id - which is true for non-G Suite accounts.
However, when app is published by a G Suite account, the app can get accessing user ids within the same G Suite domain even when it's set to execute as publishing user.
Thanks Niek and TheMaster for your help!
If you just need user ID, why do you ask for all those permissions?
Possible Solutions:
2 web-apps- One running as you and another as user accessing (with only profile) permission. The second one will be the actual web interface and POST necessary information to the first one with privileges. OR
Implement your own web-app Google-sign in1
Use the least permissive2 scope3
I'm trying to create a website to authenticate users through the use of a throwaway password where the assumption is that the user might not use the website again (basically a one time access).
I have done my research on OTP and various solutions to authentication but these don't seem to fit my requirements, most of them seem to rely on users having login credentials to the website whereas my system would allow them access without the need for registering.
The implementation of passwordless authentication by Auth0 seems to fit what you're describing. Even if you were not considering a third-party provider it may be useful to go through the documentation.
Basically, a user can login to a site without any need for a sign-up process. They can do so just by requesting that a one time code is delivered to them, for example, either by email or SMS.
This way, they can get quick access without having to setup a user and in the event that they do come back your application can recognize this because they will most likely be using the same mechanism, that is, you can use the email or mobile phone as the unique identifier.
Disclosure: I'm an Auth0 engineer.
If you do not require your users to register, why do you need authentication at all?
Why not just set a cookie with an unique identifier on the first visit? You can store data at the server side associated with that identifier. Keep track of when you last saw the user, and if they do not return within a certain period, you can delete any data you stored for that user.
I am looking for a way for my users to be able to login to both of my Joomla sites (one running 1.5 and the other 1.6) using the same credentials. For example, if a user registers to my Joomla1.5 portal, when they use that same info for my Joomla1.6, they get logged in without having to re-register and vice versa.
I guess an authentication plugin would be the best solution in combination with a XML-RPC service? Joomla1.5 site's plugin is triggered which "communicates" with the Joomla1.6 site where the user is already registered, if the credentials check out, a new user is created and the user automatically gets logged in.
Thanks in advance for any ideas/help.
You are trying to do two very different things that will require two very different plugins. First, you need a bridge to handle user table synchronization. You not only have to create a user for each site, you have to sync everything about both accounts each time anything changes. This would include changing email address, password, or even user name plus any other related data such as the use groups that the user belongs to. A good place to start would be jFusion, which is designed to bridge Joomla with other software packages but can certainly be modified to bridge Joomla sites. JFusion also has the added advantage of creating user sessions for each connected software package for a single unified login, which would be the second piece of the puzzle you would need to solve once you get the users sorted out.
http://www.jfusion.org/
I am thinking of tying in a Facebook JavaScript-based application with an existing website that has it's own user accounts, but have a question about a specific user situation.
The website is run almost 100% of the time from 'shared' computers, like those found in a career center. User A comes to my website, signs into the site and then authorizes the Facebook app, which stores their session in the browser, along with, effectively, signing them into Facebook.com.
User A now leaves my application by signing out of my site - but not closing the browser.
User B arrives, logs into my site with their login, but the Facebook session is still active (due to the browser staying open), so any FB app integrations I've included will show as if it is still user A, correct?
So the question is, what are the recommended ways to deal with this? Two options come to mind:
When the user signs out of my website, I fire an FB.logout call, so that all of the sessions are killed. Pros - I can ensure that user's signing into the site will not have old sessions hanging around. Cons - a user who is returning shortly after leaving will have to re-login to FB as well as my site to see the FB integrations - I'd love to avoid the user ALWAYS having to do two logins. Secondly, forcing the FB.logout when they leave my site kills any active sessions they have at facebook.com, which makes for a bad user experience as they would not 'get' why logging out of my site has anything to do with facebook.com, and will then have to re-signin to facebook.com.
The second option would be that when the user authorizes the FB app, I take their member ID and store that locally and persistently (database). Then, when a user returns to the site and signs in, I check their FB auth status, and if logged in to FB, pull their member ID and check it against the one I have stored locally. If they match, I have the correct user, if not, I do FB.logout and have them sign in to FB. Pros - this should ensure I always have the correct user to the site. Cons - not sure if getting, storing the member ID is feasible.
Any suggestions or pointers to the 'best practice' when it comes to ensuring that the current user is indeed the one associated with the FB account, specifically in this 'shared computing' situation where sessions may overlap?
Thanks
The second option looks to me to be the better choice. You can indeed store the users facebook id. By storing it locally i'm assuming you are talking using a cookie; however storing in a database is just as feasible.
Facebook user id's should be stored with a BIGINT(20) data type - such are the recommendations from facebook.
Taken from the user section of the facebook api refrence :
Looks like they changed their recomendations...