in guest page
<script>
console.log(document.cookie)
// ""
</script>
But in Developer Tools` Application Cookies has values.
Related
I have a single page app that consists of these files:
index.html
authConfig.js (defines MSAL configuration and scopes)
graphConfig.js (defines graph endpoints used in the app)
ui.js (defines all the UI functionality)
authPopup.js (creates the main myMSALObj instance and signin and signout functions)
graph.js (contains the function that calls the MS Graph API endpoint using the authorization bearer token scheme)
My question is in regards to whether I need to 'hide' the following values in the authConfig.js file when adding the files to a GitHub repo (using environment variables etc):
// application/client id of app registration in Azure portal
clientId
// full directory URL, eg: https://login.microsoftonline.com/<tenant-id>
authority
// full redirect URL
redirectUri
My recollection is that it's not required because the values are easily discoverable via other means, but would like that confirmed.
The full contents of authConfig.js are below:
/**
* Configuration object to be passed to MSAL instance on creation.
* For a full list of MSAL.js configuration parameters, visit:
* https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/configuration.md
*/
const msalConfig = {
auth: {
// application/client id of app registration in Azure portal
clientId: "*******",
// full directory URL, eg: https://login.microsoftonline.com/<tenant-id>
authority: "https://login.microsoftonline.com/*******",
// full redirect URL
redirectUri: "http://localhost:3000",
},
cache: {
cacheLocation: "sessionStorage", // This configures where your cache will be stored
storeAuthStateInCookie: false, // Set this to "true" if you are having issues on IE11 or Edge
}
};
/**
* Scopes you add here will be prompted for user consent during sign-in.
* By default, MSAL.js will add OIDC scopes (openid, profile, email) to any login request.
* For more information about OIDC scopes, visit:
* https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#openid-connect-scopes
*/
const loginRequest = {
scopes: ["User.Read"]
};
/**
* Add here the scopes to request when obtaining an access token for MS Graph API, for more information, see:
* https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/resources-and-scopes.md
*/
const tokenRequest = {
scopes: ["User.Read", "GroupMember.Read.All", "Group.Read.All", "Directory.Read.All", "Group.ReadWrite.All", "Directory.ReadWrite.All", "Team.ReadBasic.All", "TeamSettings.Read.All", "TeamSettings.ReadWrite.All", "User.Read.All", "User.ReadWrite.All", "Sites.ReadWrite.All"],
forceRefresh: false // Set this to "true" to skip a cached token and go to the server to get a new token
};
For reference, index.html contains this:
<script src="https://alcdn.msauth.net/browser/2.26.0/js/msal-browser.js"
integrity="sha384-fitpJWrpyl840mvd9nBFLGulqR4BJzvim0fzrXQKdsVh2AQzE4rTTJ0o5o+x+dRK"
crossorigin="anonymous"></script>
<script type="text/javascript">
if (typeof Msal === 'undefined') document.write(unescape("%3Cscript src='https://alcdn.msftauth.net/browser/2.26.0/js/msal-browser.js' type='text/javascript' crossorigin='anonymous' %3E%3C/script%3E"));
</script>
<script type="text/javascript" src="js/authConfig.js"></script>
<script type="text/javascript" src="js/graphConfig.js"></script>
<script type="text/javascript" src="js/ui.js"></script>
<script type="text/javascript" src="js/authPopup.js"></script>
<script type="text/javascript" src="js/graph.js"></script>
How to sign out from sign-in-with-google app. I want to sign out in such a way that it again ask for password when again sign in with google.
I don't want to remove account from my browser.
I just simply want to forget my browser.
Sign out
<script>
function signOut() {
var auth2 = gapi.auth2.getAuthInstance();
auth2.signOut().then(function () {
console.log('User signed out.');
});
}
</script>
Its from the official document https://developers.google.com/identity/sign-in/web/sign-in#sign_out_a_user.
If you want to logout of an application as a user of any website you can do it in your account's security preferences: https://myaccount.google.com/permissions
at main.js I got user information with access_token from oauth.
now I want to change value at index.html with user name
here, how can I send user name to index.html?
I know event.sender.send but isn' it located at ipcMain.on a result of ipcRenderer.send?
I want to sent some value after I got access_token
thanks
Assuming that your index.html page is just the main page of your renderer process and isn't an external page that you're hosting in a <webview>, you can just send the value to the renderer and have it change whatever it needs to change in your index.html:
index.html:
<p id="myParagraph"></p>
<script> require("./renderer.js"); </script>
main.js:
const mainWindow = new BrowserWindow({...});
mainWindow.loadFile("./index.html");
// ... later we get the `accessToken`
mainWindow.webContents.send("got-access-token", accessToken);
renderer.js:
ipcRenderer.on("got-access-token", (event, accessToken) => {
document.getElementById("myParagraph").innerText = accessToken;
});
Let's say I want to obtain an authorization token from google via javascript/python/anything on localhost. How can I do that? After sending a authorization request on "https://accounts.google.com/o/oauth2/auth?..." user has to allow it, but there is no way my script obtained the token back (since google cannot redirect to localhost). Or is it?
I have been dealing with OAuth for the last couple of days, and I'm not sure I 100% understand it...but I will try to relay what I have learned.
Here is the code I used to ask a question earlier this week...
index.html
<!doctype html>
<html>
<head>
</head>
<body>
<p>Tripping all day...</p>
<p id="output"></p>
<script src="auth.js"></script>
<script type="text/javascript">
function init() {
console.log('init');
checkAuth();
}
</script>
<script src="https://apis.google.com/js/client.js?onload=init"> </script>
<script>
document.getElementById("output").innerHTML = "Coooooorrrrrraaaaalll";
</script>
</body>
</html>
auth.js
var CLIENT_ID = 'xxxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com';
var SCOPES = 'email';
function handleAuth(authResult) {
console.log('handle auth');
console.log(authResult);
}
function checkAuth() {
console.log('check auth');
gapi.auth.authorize({client_id: CLIENT_ID, scope: SCOPES, immediate: false, cookie_policy: 'single_host_origin'}, handleAuth);
}
This uses the Gapi javascript client Google provides. When I call gapi.auth.authorize and give it my Client ID I set up in the Developer Console, it shows me the Google account authorization popup, and then I believe that the Gapi object has a method that adds the OAuth token to the Gapi object itself. I didn't include a redirect URI when I set up my credentials, by the way.
After I got the authorize call working, I could then call oauth2.userinfo.get() to get my token to use with their APIs.
var request = gapi.client.oauth2.userinfo.get();
As for the locahost, I used just the IP address of my development server which doesn't have a top level domain attached to it. Localhost may work the same way?
In Ryan's Railscast on Facebook authorization, he adds some Facebook SDK javascript at the end to "degrade facebook client side authorization with server side authorization." However, I do not see the use of it. If we already set up the authorization from the server side using omniauth, why do we have to add the client-side authorization again? What difference does it make?
The referenced javascript code is (From the linked Railscast):
jQuery ->
$('body').prepend('<div id="fb-root"></div>')
$.ajax
url: "#{window.location.protocol}//connect.facebook.net/en_US/all.js"
dataType: 'script'
cache: true
window.fbAsyncInit = ->
FB.init(appId: '<%= ENV["FACEBOOK_APP_ID"] %>', cookie: true)
$('#sign_in').click (e) ->
e.preventDefault()
FB.login (response) ->
window.location = '/auth/facebook/callback' if response.authResponse
$('#sign_out').click (e) ->
FB.getLoginStatus (response) ->
FB.logout() if response.authResponse
true
UPDATE:
One of the reasons we need to integrate FB.login authorization with the server-side authorization might be that the Omniauth server-side authorization does NOT work if it's accessed within the Facebook iFrame. If the user accesses the application for the first time, the application must ask for permissions; however, oAuth permission dialog cannot be loaded within the iFrame to prevent clickjacking. Calling FB.login can avoid such problem, because it will show the permission box as a popup(Omniauth popup option will not work).
So now I have a genuine reason to integrate client-side authorization, but the code from Railscasts does not work with my current settings. I've chosen to do it the following way.
Right now, I have the following script in my application.html.erb:
<script>
// Additional JS functions here
window.fbAsyncInit = function() {
FB.init({
appId : <%= ENV['FACEBOOK_KEY'] %>, // App ID
status : true, // check login status
cookie : true, // enable cookies to allow the server to access the session
xfbml : true // parse XFBML
});
};
// Load the SDK Asynchronously
(function(d){
var js, id = 'facebook-jssdk', ref = d.getElementsByTagName('script')[0];
if (d.getElementById(id)) {return;}
js = d.createElement('script'); js.id = id; js.async = true;
js.src = "//connect.facebook.net/en_US/all.js";
ref.parentNode.insertBefore(js, ref);
}(document));
</script>
And in my view, I have the following link invoking the Facebook log in action:
<%= link_to 'log in with facebook', '/auth/facebook', id: 'fb_log_in_link' %>
I add the following script to the view page where I have the login link.
function login() {
FB.login(function(response) {
if (response.authResponse) {
window.location = '/auth/facebook/callback'
}
});
}
Also, I need to change the link to call the function instead of directing to /auth/facebook/
<%= link_to_function 'log in with facebook', 'login()' %>
Done! The server-side and client-side authorization are fully integrated. Since I was still confused after watching Ryan's Railscast, I want to add a little bit of explanation for those who might be also confused.
The way this works:
Facebook SDK is initailized when the while the page is loaded.
The user clicks the "log in with Facebook" link.
FB.login function is called by the link, and the user goes through all the permissions process (e.g. permission dialog showing up asking for the user's permissions).
Then, the user is directed to /auth/facebook/callback. From routes.rb we have the line match 'auth/:provider/callback', to: 'sessions#create'. Therefore, now the server will either create a new user or simply create a session if the user has already registered before.
Done! The user is logged in.
Merging server-side and client-side authorization has two major advantages:
1. If the user is logged into the application either inside Facebook(via appcenter) he will be logged into the application outside Facebook as well. Vice versa, if the user logs in outside Facebook, he will be logged in automatically if he accesses it within Facebook after.
2. Logging in with /auth/facebook does not work if the user logs in within Facebook iFrame. To prevent clickjacking Facebook prohibits prompting users to auth permissions dialog within Facebook iFrame. The only way to avoid this is to open the dialog in a separate popup, and logging in with FB.login solves the problem.
the short answer is - you don't.
you can choose between client side login (via javascript SDK) and server side login using omniauth.
the disadventage of server-side login is overloading the server for a call you can do from the client.
the advantage is that usually the token is longer (3 months token and not 1-2 hours like client side).
i suggest combine the two. use the client side for initial login, once you do that have an async call from the server side for extended token (only if you have to).
It just says,
Facebook provides a JavaScript SDK that we can use to authenticate a user on the client-side so that it doesn’t look to them like they’ve left our application then returned.
It means that this is for the client side understanding that when user returned from the application, it doesn't look like that they have indeed left it.