Setup:
Using the js library and following the client-side login/auth flow of my C# Xamarin projects.
CORS is setup and initial login is fine:
this.client = new WindowsAzure.MobileServiceClient(<endpoint>);
this.client.login(<provider>);
I store the returned "userId" and "mobileServiceAuthenticationToken" for future use.
Problem:
Calling the invokeApi of azure-mobile-apps-client:
this.client.invokeApi("myCustomerController", { method: 'GET' })
returns:
401 (Unauthorized)
Am I missing something? I'm expecting the client to be ready to make calls to my back-end services.
I've tried using the existing client directly after the login without success.
It also fails when setting the "userId" and "mobileServiceAuthentication token" of a new client.
The custom ApiController I'm calling is working fine when called from elsewhere (such as C# MobileServiceClient).
I assumed the login would get the client ready for use but not in my case. I had to call login, get the userId and token returned in the result, then set currentUser manually before make any future requests.
this.client = new WindowsAzure.MobileServiceClient("https://...");
this.client.currentUser = {
userId: "xxxxx",
mobileServiceAuthenticationToken: "xxxxx"}
The login method returns a promise. Can you confirm you are indeed waiting for the promise to be fulfilled before proceeding to do an invokeApi call?
Related
New to docusign and have been reading the docs, and I can't seem to get around these problems.
Per the docs it says that gets a code getAuthorizationUri() which can then be used by generateAccessToken() to get a token. After that, the token can be used to explore the API with other methods.
I'm stuck in two places: First I configured my get Authorization like this (typescript)
import { ApiClient } from 'docusign-esign'
const apiClient = new ApiClient()
const url: string = apiClient.getAuthorizationUri(
config.docusign.INTERGRATION_KEY,
['signature'],
'http://localhost/',
'code',
'ready'
)
console.log(url)
I get the url fine, but it is always starts with acccounts.docusign as opposed to the required account-d.docusign that's required because my app is in dev.
Secondly, I can't figure out how to transition that URL into a code programtically. Yes, I can copy and paste it from the browser URL (as in the instruction videos), but obviously my next step is to run something like:
async getToken(authCode){
const token = await apiClient.generateAccessToken(
INTERGRATION_KEY,
SECRET_KEY,
authCode
)
console.log(token)
return token
}
To change authentication from prod to demo, you need to make this call:
apiClient.setOAuthBasePath("account-d.docusign.com");
You may also want to change the URL for API calls if you use this later like this:
apiClient.setBasePath("https://demo.docusign.net/restapi");
I suggest using an OAuth npm package and not doing this yourself.
See how it's done in the quickstart (Pick Node.js and Auth Code Grant)
I am using the xero-node module to create an app for Xero with NodeJS.
For some reason every single request for a refresh token is coming back as invalid grant
i have been taken the code and made the callback attempt to grab the refresh straight after i do the auth so I can ensure thats its the latest token and still does the same thing.
Code is below this method is called when Xero passes back to the app (callbackURL)
The error i get is "invalid_grant" it does not give any other errors and there is no errors logs in Xero so very unhelful.
exports.callback = async function (req, res) {
const tokenSet = await xero.apiCallback(req.url);
try {
const newTokenSet2 = await xero.refreshWithRefreshToken('ClientID, 'ClientSecret', tokenSet.refresh_token);
}
catch(error){
console.log(`ERROR refresh: \n ${JSON.stringify(error.response.body, null, 2)}`);
};
///console.log(tokenSet);
};
Any ideas ?
Without seeing more of your code for context it's bit tough to tell. I'm assuming you're not actually sending 'ClientID' and 'ClientSecret' as strings.
I would refer you here for refreshing with a fully initialized client leveraging openid-client:
https://github.com/XeroAPI/xero-node-oauth2-app/blob/f1fbd3a08e840e54e8ce57f7050ddde6686208d8/src/app.ts#L233
Or here, to initialize an empty client and refresh by passing the client, secret, and refresh_token:
https://github.com/XeroAPI/xero-node-oauth2-app/blob/f1fbd3a08e840e54e8ce57f7050ddde6686208d8/src/app.ts#L236
I think what's happening is that you're using the second method but with an already initialized client. Again, tough to tell with limited context. If this doesn't resolve it please post more detail.
[ Post has been edited: see below for answer ]
I am trying to make a Vue.js2 application using this boilerplate https://github.com/vuejs-templates/webpack
I am stuck on the Authentication process, using this library: https://github.com/websanova/vue-auth and attempting to use JWT as the authentication method. Never having rolled my own authentication before, I am slightly lost.
Packages I have installed which may be relevant: passport, passport-jwt, jsonwebtokens, passport-local, passport-local-mongoose
Looking at my logs I get a successful login response, but then it attempts to get /auth/user and responds with a 401 (unauthorized error). Perusing the auth library code, a GET req to /auth/user seems to be the expected behavior.
Here is the login code (client side):
methods: {
login() {
this.$auth.login({
body: this.data.body
success(res) {
console.log('Success: '+this.context);
this.localStorage.setItem('auth-token', res.body.token);
},
error(res) {
console.log("Error: " + this.context);
this.error = res.data;
},
rememberMe: true,
fetchUser: true
});
}
}
And here is the appropriate code server-side:
Removed Link | See Edits Section *
What I am sure of is this:
the server does in fact create a JWT which is valid (checked on jwt.io) during the login request. It does not appear to be set anywhere afterwards. It just sits there and then dies. There are mentions of an Authorization Bearer header in the response, which I am certain is not being set. Nor do I understand where or how to do this. There is no token set in localStorage after the login request. I'm not sure if this should exist, but think it likely that it should. In my console, searching local storage yields some strings and large integers, but no mention of a token in it.
Edits (8+ months later)
Gist to Solution here (slashes replaced by dashes in filenames):
https://gist.github.com/wcarron27/b0db7a16df9ceff924d4a75050093c55
The reason my login method originally did not work was that the localStorage token was not set correctly, and thus failed to pass the getData method on the client-side redirect. vue-auth does this by default. By editing the url it hits in the vue-auth config, I was able to direct it to the proper route(BUT only after I properly set the localstorage token. Use Vue.http.options.rootUrl (or something, it's in the main.js file in the gist) to set the Authorization header.
In the code, You must register vue-auth on the client side main.js, and call to it in the Login.vue "login" method. The client side config directs the http calls to the specified route in main.js. In the callback, the user and tokens are set in localStorage and the Vuex store.
The Http reqs go the the API side and hit the route in accounts.js. That route uses a passport strategy defined in ./util/passport.js, as well as a setJWT function defined in ./util/jwtLib.js.
After this, the client is redirected to a route of my choice, and data is populated by my store and ajax calls. Keep in mind, that while this should solve logins, i have not verified code correctness, as basically I would have needed to post the whole of two separate codebases.
Additionally, this does not account for refresh errors. State is dropped on refresh, so do not rely on vuex for persistence. A combination of localStorage and vuex does the trick, though.
I didn't verify this but, does remove the 'this' from your code on line 7 do the magic?
methods: {
login() {
this.$auth.login({
body: this.data.body
success(res) {
console.log('Success: '+this.context);
// original code here --> this.localStorage.setItem('auth-token', res.body.token);
localStorage.setItem('auth-token', res.body.token);
},
error(res) {
console.log("Error: " + this.context);
this.error = res.data;
},
rememberMe: true,
fetchUser: true
});
}
}
Using Asana's NodeJS module (https://github.com/Asana/node-asana) with OAuth, how should I handle expiration of the access_token? Does the client provide some mechanism that I should use to detect this? Does it provide something I should use to get a new access_token using the refresh_token? I haven't been able to find any discussion of the refresh_token in the documentation.
I've registered my app and I'm able to successfully get credentials using the Client.app.accessTokenFromCode API. Something like this:
function handleOauthCallback(req, res) {
var client = Asana.Client.create({
clientId: CLIENT_ID,
clientSecret: CLIENT_SECRET,
redirectUri: computeRedirectUrl(req)
});
client.app.accessTokenFromCode(req.query.code).then(function(credentials) {
// store credentials
}
}
I'm storing the entire credentials object that comes back from this call and later creating a client using those credentials. Something like this:
var client = Asana.Client.create({
clientId: CLIENT_ID,
clientSecret: CLIENT_SECRET,
redirectUri: computeRedirectUrl(req)
});
var storedCredentials = getStoredCredentials();
client.useOauth({ credentials : storedCredentials });
Now that I've got a client that's initialized with the credentials I got back from Asana (which includes an access_token and refresh_token), how should I handle expiration of the access_token? Do I need to check whether it's still valid myself and ask for a new token using the refresh token? Or will the client handle it for me automatically? If the client handles it, how do I find out when it gets a new access token?
Update
Reading the code, it appears that the client will try to use the refresh token if the access token is no longer valid. But I don't see any kind of notification that I can hook into to find out that there's a new access token. Is there a recommended strategy to handle this?
(I work at Asana). This is a great question, and we should add answers to the documentation.
The dispatcher can be passed an option called handleUnauthorized which is a callback to run when it gets a 401 (which if you started with good credentials should only happen when your token expires). It's documented in the code.
The default behavior of this option is to call Dispatcher.maybeReauthorize, which will make the backend request to get a new access token if it has a refresh token.
So if you just want the dispatcher to transparently refresh the access token, you don't need to do anything, it should "just work"! But if you want to intercept this process, you can pass handleUnauthorized in the dispatch options and then do whatever you want, possibly including calling the default method.
If you want to see the new access token, well .. the Authenticator class is abstract and we haven't provided a robust way to extract credentials from it; maybe we can add that. If you really need this, you could assume it's the oauth flavor with something like:
handleUnauthorized: function() {
return Dispatcher.maybeReauthorize.call(dispatcher).then(
function(reauthorized) {
if (reauthorized) {
onCredentials(dispatcher.authenticator.credentials);
}
return reauthorized;
});
}
This isn't beautiful, but it should work for you. Just be aware we may evolve this interface a bit over time and you may have to tweak it in the future.
I have a startup module in angularjs. This module is just to login and have public information (login, prices, newsletter...). I have many roles and for each role, i have an app (angular module). I made this architecture because i have complex module for each role and it was impossible to put all roles in one module.
So, for login, i use jsonwebtoken in node like this :
var token = jwt.sign(user, config.secureToken, { expiresInMinutes: 20*5});
res.json({ token: token, user: user });
It works perfectly. I can login into my app. After that, i have to propose a list of roles to redirect to the right module.
In angular, I have AuthHttp service that adds security headers (with token) to call rest service with $http.
How can i redirect to 'mydomain:port/anotherModule' with $location or $http ?
With this code in nodejs :
app.get('/secondModule', expressJwt({secret: config.secureToken}), function (req, res) {
res.render('restricted/secondModule/index.html');
});
NodeJs sends an html code in response and does'nt redirect...
And if i do this in my angular controller :
location.href = route;
i have this result on nodejs console :
Error: No Authorization header was found
I am not sure about the libraries you are using, but issue seems that you are loosing the token because you navigate to a altogether new page.
Based on your auth library you need to pass the token that you get after auth from one page to another.
The options here are to either use browser sessionStorage or querystring to pass the token along and at it back to the http header collection on the new page (module)
This is an old post but I recently took a long time to figure this out. I may be wrong but I believe nodeJS/expressJS can't read the token from the session storage. I believe you will need to pass the token via the request header using AngularJS.
This depends on the front end that you are using. For me, I am using AngularJS and I have to do something like this.
angular.module('AngularApp').factory('authFactory',
function($window){ //the window object will be able to access the token
var auth = {};
auth.saveToken = function(token){
$window.localStorage['token_name'] = token; //saving the token
}
auth.getToken = function(){
return $window.localStorage['token_name']; //retrieving the token
}
return auth;
}
.service('authInterceptor, function(authFactory){
return { headers: {Authorization: 'Bearer "+ authFactory.getToken()}
} //the last line gets the retrieved token and put it in req.header
Then, you just need to include 'authInterceptor' in all the http methods when you communicate with the backend. This way, nodeJS will be able to pick up the token.
You can see the Authorization field in req.header if you use the chrome developer tool and look at the Network tab. Hope this helps.