I am developing and testing a local service fabric cluster in a 5-node environment.
I used Microsoft.AspNetCore.Identity.
However, if I try to sign-in, I get not signed-in page of 4/5 chance.
I've looked at the documentation and tried several things, but it still does not work.
(ex. AddIdentity, UseAuthentication, AddDistributedRedisCache, AddSession, UseSession)
What is the simplest way to share a user's authentication status via Redis Session when use Microsoft.AspNetCore.Identity?
Related
I have a Google Apps Script deployed as a web app. It is configured to run as me, as it creates and amends events on my calendar and uses a Google sheet of mine as its data store.
There is a requirement that users are NOT required to have a Google (or any other specific type of) account to log on, so I have written a bespoke login function.
The problem I have is reliably identifying the user session.
User properties/cache doesn't work as the user is me for all users.
Is there a way I can identify something unique about the actual user to identify their session?
I understand that web apps run on Google's server and that I have no access to the user's browser so cookies and similar technologies are not an option.
I'm building an application with Vue and Electron, and I'm wondering what the best approach is for authenticating users.
I'm using JSStore as a wrapper for IndexedDB as my database. I'm familiar with using bcryptjs as a means for authenticating users when I create Node backend and have traditional /login or /signup routes.
But this is where I'm starting to get confused. Do I need to set up a Node server to start up when my application starts up? Because given that I'm using IndexedDB, I don't know that it makes sense to have a process of Sign Up --> Request to Node Server --> Send data back to browser
Would I be better served using a different type of database? Could I do something such as adding bcryptjs to the Vue prototype, so that's it's accessible where I need it to work with JS Store? Are there security concerns that I should be aware of with an approach like that?
At this point I'm stuck, and have more questions than answers. I've done some looking around for articles, and I find a lot of content about setting up authentication with Vue, but not within the context of an Electron application. I'm not sure how that variable changes things.
Any advice or direction would be greatly appreciated.
JsStore is client side technology, which means if you are setting up authentication in client side, it will be available only to that device.
Let's understand it more by use case -
Say your application named My Awesome app has authenticaion implemented. User register it and then they are able to use it after registration. They are logging out and signing in again with registration data and everything is working normal.
Here is what wrong with this approach -
User buys another pc and installed application My Awesome app, he tries to login but unable to login because registration data does not exist on their new PC.
Due to some issue, user hard disk crashed & he installed new hard disk. Same thing as above he is not able to log in.
So it is recommended to implement the signin on some server & keep data there.
I am working on a PWA using Vue.js. For syncing data we use PouchDB on the client and a remote express-pouchdb server.
When starting the application, we want the user to login, regardless if online or offline.
So our idea is the following:
When opening the website for the very first time, the user has to login at the remote-db
All users are synced to the local pouchdb-instance
When the PWA is opened and the client isn't online, then authenticate against the local-db, otherwise the remote-db (and also keep the users in sync).
Is it possible to achieve this behavior?
I've seen some authentication plugins, namely pouchdb-authentication, pouchdb-auth and pouchdb-seamless-auth, though im not exactly sure, if these can be used for our requirement.
You could achieve it by encrypting your pouchdb https://github.com/calvinmetcalf/crypto-pouch
Then if you are offline instead of login you enter the password to decrypt. The problem is that if you are logged out when you open the app offline there is no way you can get user info.
So you need to store user info locally, in a _local document that doesn't replicate. And since offline authentication is not supported, you have to check yourself user/password stored locally. So you will have 2 separate login for online(you can do this easily with pouchdb authentication) and offline.
Personally the best solution is to make a dump of pouchdb on logout. And then delete local pouchdb (data in browser). If you are online, you proceed to standard login and upon success load the dump and sync to remote. If you are offline, check locally stored user/password and again upon success load dump.
Additionally, you can encrypt the dumped database as well.
I am trying to authenticate a user inside a desktop application using the web api. I am not using a browser, I am using straight up GET and PUSH calls to the endpoints of the Spotify servers. Immediately I ran into some problems. It appears that upon the initial GET command to "accounts.spotify.com", the returned response includes HTML with a javascript function that runs and is responsible for dynamically generating HTML that you see on the initial login page. If you look at the Javascript function, it is clear that this is what is going on, however, you can also see this code is obfuscated and not meant to be used by us, the developers! (Link to Javascript code here for reference: Javascript function)
So my question is, while I can probably reverse engineer the code to get this working, would this be against the Spotify developer TOS?
Thanks!
Spotify's authentication happens through oauth, and a big part of user authentication as per the oauth rfc is where the user delegates permissions to your app to carry out API calls that affect their account, or return information about them. That's the web page you're seeing - it must be presented to your users so that they can delegate permissions so that Spotify can give your app an access token. It doesn't necessarily need to happen in a browser - it can happen in a web view inside your desktop application - but it does need to be loaded over https, and your application must not alter or reverse engineer the Spotify permissions delegations page.
As you correctly guessed, reverse engineering any Spotify APIs is against terms of service.
For more information on authorization on the Spotify platform, I'd recommend having a look at this guide.
Hope that helps! Please ping me if you have any more questions.
Hugh
Spotify Developer Support
I have spent the last couple of nights bashing my head against the wall amongst a see of conflicting out of date documentation and semi-helpful blog posts that were/are appropriate to what I am trying to do.
Essentially I want to write a wee personal app do download my images from PicasaWeb/Google+ and store them on my local hard disk.
I have managed to do the following:
Figured out the GData API for the appropriate request to get private album data (works fine in my 'google-logged-in' chrome browser)
Got the correct private data back from my GData URL with the token generated by the OAuth playground.
Managed to get an OAuth2 token back from https://www.googleapis.com/oauth2/v3/token using JWT.
However - when I try my access token I generate myself I get back a forbidden response with the message 'Not authorized to view access private'.
I am pretty stumped - my only guess is that my service account configured in google developers console doesn't actually have access to my personal google stuff like google+ photos. When I look in there I can see the OAuth playground has access. How do I give my app access - and do I need to in this scenario?
Thanks in advance,
Robert
"my only guess is that my service account configured in google developers console doesn't actually have access to my personal google stuff".
Totally correct.
I guess I see 2-3 questions per month on SO where people have made the false assumption that a Service Account is some kind of proxy to their Google Account. It isn't. It's a completely new and independent account.
The two approaches you can take are:-
Share the items to the Service Account so it has permission to access them.
Give your app direct access to your Picassa account. See How do I authorise an app (web or installed) without user intervention? (canonical ?) for the steps involved.