There is a portal that a company's users are familiar with, and we will put a link to login to a different portal on a different machine. This process would not require username/password check, just hitting the link will log them in.
How can this two delivered in secured way? We don't want that anyone with the link to be able to log in, how can we make this to work between the two platforms?
I'm presuming the two portals aren't able to share sessions/cookies. If they are you can just use those to keep track of who is logged in where.
In the situation where that's not possible, you could use an authentication API, which you could query to see if a given user_id is logged in on that portal. This could be a very simple API which returns a yes or no, or you could develop it to be more complex.
Additionally keep in mind that there are Open Source choices out there. Open ID is a system that stackoverflow uses, for example.
Easiest method would be script on main site, that waits for session ID in POST/GET input, if session exists, it outputs user name. The new site server, when user comes in, reads in cookie with session ID, sends a request to main site server script and asks if session ID exists, if exists, uses that user name, for new site server.
Related
I'm trying to make something like this:
Basically, I have one site (the main site) where people authenticate and create accounts. Their data is sent to a MySQL database.
On the other side, there’s another site. That site needs the users username (because I’d like to show it) and if they are not logged into their account on the first site, I want the second site to redirect them to the first site where they eventually create and account or login.
I’m also going to give an example where this is used. Let’s take Microsoft, they have their Microsoft accounts and a login page, and other services such as azure and office. They all use Microsoft’s original login without them needing to login each time they open that service, nor even the first time if they are already logged into their Microsoft account.
(I have the main site coded in PHP)
Could you maybe help?
You can use session variable.
In your main site you can save login in a variable like $_SESSION['user_auth_ok']
In every page of both websites you can use:
<?php
session_start();
if (!isset($_SESSION['user_auth_ok'])) {
header("Location: main-site/login.php");
}
So, everytime a not authenticate user try to access a reserved page will redirect to main site login page.
I have this app that uses data from gmail accounts. I have been able to create a php site that retrieves the oAuth tokens (online and offline) and later the necessary user information from the mailbox, all using the Google php api. Now to my problem:
When a secondary user logs into gmail in a browser that was previously used by an authorized user, the credentials seems to "stay". So the 2nd (or 3rd or nth user) can see data non-related to them, which is also a security hole. But most important: every loged in user into gmail is seeing only the data of the 1st logged in user.
The question: Is there a way I can use Google PHP API or Google JavaScript API to retrieve the user name of the current gmail session?
This is the current php piece of code I've been using to retrieve the user data:
use google\appengine\api\users\User;
use google\appengine\api\users\UserService;
session_start();
$user = UserService::getCurrentUser();
$userEmail = htmlspecialchars($user->getEmail());
The idea is that the app uses the current gmail user information to query a database and then retrieve the data for that specific user - and only that logged in user. If the user is not authorized, then prompt for the authorization window and ask for permission.
Any ideas or suggestions are welcome.
UPDATE (Sept 7, 2015):
I have made a change in the app.yaml so every logged in user in gmail gets served a different uri from my app. That works just fine. Now I face a new issue: how can I make the PHPSESSID and SACSID cookies to use an specific path instead of the whole domain? That way - theoretically - I can have several logged in users each and every one connecting to a different subfolder.
I've read the whole documentation about the UserService but it seems all I can do is redirect to this:
UserService::createLoginURL($_SERVER['REQUEST_URI']);
And that takes care of the authentication.
The question: How can I restringe the scope so the cookies gets the appropriate folder path?
The main issue is that once you log in to App Engine (via the UserService), that a user session has now been created in your App Engine application, and therefore it doesn't really matter what you do in GMail or any other Google application, as the session has already been created, and persists within your application.
The App Engine UserService was available way before secondary logins were even possible, and it hasn't been updated since. So this use case probably wasn't a consideration when the API as developed.
I have a wordpress site, and I want to put a link on that site so that users are redirected to another PHP site.
But here the problem is that the other php site uses authentication, i.e. users need to give username and password before they can enter.
I want to develop a link that users can simply click on and get to the other site directly.
I can give the username and password for the php site, but the requirement is that the user users are not asked for username and password.
you have to make a new php file(in the 'php site') that assign the session variable to the linked users, and then it redirect them to the main page of the 'php site'
U have to write an authentication function on the other php site.. when the user clicks on the link of the wordpress site redirect him to that authentication function, along with his credentials, where the users will get logged in automatically and get redirected to your php site.
if i get you right, i think the best way is to generate the link in wordpress site with a parameter : http://www.linktophpsite.com/?autologin=true
Then at php site you could get the element and if it is set to true, you can log the user to your site. If you want single sign-on on both sites, that's totally different. I recommend you to read articles about single sgn-on on php
If you have no control over the target site, then your options are very limited. You can't just provide access to material that requires login credentials without providing those login credentials.
Your best, and most secure, bet is to include the target site's login fields directly from their site in an iframe. The user logs into the other site, you track the iframe onload event to see that it changed, and then redirect the user to the page in question. This is better because it keeps you from handling the login details directly on your site.
I cannot guarantee that this works as simple as that, I haven't tried it and this page seems to indicate that at least some of the possibilities with cross-domain iframes are no longer relevant with modern browsers (I didn't read the page in detail, just trying to give a starting point).
Im going to make an app that will be able to sync data between android mobile phone and a webpage database. At the moment im trying to think things through and figure out the hard parts. The first thing that crosses my mind is the login part.
The best idea i have is that before starting my app user has to log in. When he logs in it sends user data to my web page and it returns true/false. If it returns true i make somekind of an session in my app that says i am logged in (to access app features) but also stores my username and password. Now if i press the sync button or do something else that will need communication with my webside i can check the user/password every time. Because on the web site im planning to do different actions (login, sync, something else) i need to check the login every time - otherwise a third party could just access sync action without actually logign in first.
Anyway, that my thoughts at the moment. Im sure ill ask more detailed questions when i get to coding (im a beginner with android/java) but at the moment i wish to know if the idea of the thing is good or can it be done smarter/better?
Thank you.
I'm suggesting you to create API based application so you won't be troubled if you want to create it in many platform (in case you also want to create in iOS).
What I'm usually used is using API_KEY. API_KEY is a random number generated by the PHP side to save the login session of the user. When the user login from the mobile phone (sends the username and the password) the PHP side will generate API_KEY and updatethe existing API_KEY (if the user have logged in before in other device) in the web database so the login session in the other device will be automatically expired but you must add API_KEY validation everytime you try to access the the database (sync your application) or if you want more strict you can do the checking everytime the user change the screen.
If you have some question about this feel free to ask in the comment ! :)
I need to login with my account with php curl in a website that uses facebook connect to login.
I'll take as example site one of my favourite apps: Mousehunt
As you can see, it uses facebook (of course) to login: if you are already connected to facebook, it succeeds in automatic login, otherwise it popups facebook login.
How i can login into it with php curl? I know some about curl & cookie (cookiejar, cookiefile, post etc) but not too much.
Which is the target url to post data? How can i return to that site as user logged in?
Let me explain how this sort of FB login works. There is of course the alternate method used for desktop applications, which would make it possible, but this website doesn't use it.
So heres the deal:
The login button opens a link on facebook servers containing the api key of the website and some arbitrary information. So far so good. You could simulate that easily.
Then after accepting the privacy stuff you get redirected back to the website. You can simulate that as well.
But then comes the burden:
The location you get redirected to contains an facebook token after the hashtag (#).
The website can then read this token by Javascript and use it to query the facebook api to confirm your dientity.
The reason why this is done that way is easy:
Think about it. Everyone could fake a request in the name of the website and read your private data. But everything after the hashtag is never readable by the server the request is directed to. The web browser just does not pass it and it would be violating http standards and cause an error.
The only way to access it is by javascript. And this can only be by the website serving the request (where facebook redirects to). And the domain where facebook redirects to is locked by the application key owner.
You see javascript is an essential part of the security here.
I think it is very insecure indeed because there are many possible explits, but its very easy which is a reason why this form of login is spreading so much in comparision to e.g. openid.
So to sum it up: You need simulate a fully javascript enabled browser. It is partly possible but very complex and there are no out of the box solutions for that.
well, there might be a way.
looks like facebook request don't sign the permission scope in any way.
so this basically means you can grant the application/website more permission than they even asked for.
then you could grant the website permament permission - log in the usual way - and save the cookies.
then you can send those cookies along with curl.
if the website uses servers side login authentication, which is very likely, you will still be logged in, because the access token is permament.
however there is no guarantee for that hack to stay functional.