Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 7 months ago.
Improve this question
I am trying to use the Spotify API through the python wrapper library Spotipy. I have set up environment variables (specifically the client id and client secret as well as redirect URI) to authenticate. However, whenever I try to access something that needs this authorization (i.e. accessing a user's playlist) I get the following error: tcgetpgrp failed: Not a tty. It seems to happen whenever I access the redirect URI for authorization. I have tried a few URI's, like example.com/callback and localhost:8080 but none of these seem to work. Here is the code I have so far:
import spotipy
from spotipy.oauth2 import SpotifyOAuth
scope = "user-library-read"
sp = spotipy.Spotify(auth_manager=SpotifyOAuth(scope=scope))
def edit_playlist(name):
# Find playlist for user under the name provided
print(sp.current_user_playlists())
# Return some generic done message
print("Edited!")
I can't seem to find out what the error message means, so an explanation of that would be helpful. Similarly, what should I make my redirect URI? (Not a specific URL, but ideas of what a proper redirect URI should be). Thanks!
Seems like I had at some point accidentally removed the redirect URI in my dashboard. Also, it helped to use localhost:8888/callback instead of other URL's.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 11 months ago.
Improve this question
I've been searching how to make a public http request secure and all the answers are to use a token like JWT.
But from what I understand, the reason for using this token. Isn't this to prevent someone from trying to modify someone else's data other than your own?
Then user can still manipulate his own data using his own tokens. Because when you first connect to the app, you will get a token from the server.
That person can modify his or her data at any time. Wouldn't he be able to modify the game points he has at any time? (I actually saw an answer in another answer (which said to make that http call only available once after the game is over))
but if he knows the jwt token and http request url then he still can modify right??
Are JWT tokens used in the worst case to keep someone else's data from being touched?
The JWT token is just used identify the user making API request and checking whether the user is authorized to make that request. When you decode a JWT (Firebase Auth's JWT for this example), you can read user's UID and custom claims, etc.
Passing user ID directly in API requests is not a good idea because they are usually public (e.g. your Stackoverflow ID is 18516895) and easy to guess. So I can just try passing some random numbers/string and might be able to make requests on behalf of someone else. So JWTs are mostly used for Authorization and Information Exchange.
Also checkout: Introduction to JSON Web Tokens
But suddenly I want to raise my stack overflow score. Then just checking the token is not enough for server I guess. right? How do you prevent in this case?
Allowing users to update their score doesn't seem to be a good idea. Instead the score should be done totally on back-end and can be triggered by any action such as user winning the game.
Take Stackoverflow for example, only the person who has asked the question can mark any of the answers as accepted. This is authorization. No one else is allowed to do so. After an answer is accepted, the system updated answerer's score (reputation), so there is no API request that is made from client side to increase score.
The flow could be like:
Questioner accepts an answer
Verify JWT, marked as accepted if owner of question
Increase score (reputation) of answerer
Adding to another case of single player game Tetris where the user directly needs to update server for a win and earn points as discussed in comments, it might be best to send every move to server and run all game win logic on backend instead of checking for win on client and letting users hit a /win API over and over again. If the game is completed, then credit points to user if won.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 11 months ago.
Improve this question
I've been searching how to make a public http request secure and all the answers are to use a token like JWT.
But from what I understand, the reason for using this token. Isn't this to prevent someone from trying to modify someone else's data other than your own?
Then user can still manipulate his own data using his own tokens. Because when you first connect to the app, you will get a token from the server.
That person can modify his or her data at any time. Wouldn't he be able to modify the game points he has at any time? (I actually saw an answer in another answer (which said to make that http call only available once after the game is over))
but if he knows the jwt token and http request url then he still can modify right??
Are JWT tokens used in the worst case to keep someone else's data from being touched?
The JWT token is just used identify the user making API request and checking whether the user is authorized to make that request. When you decode a JWT (Firebase Auth's JWT for this example), you can read user's UID and custom claims, etc.
Passing user ID directly in API requests is not a good idea because they are usually public (e.g. your Stackoverflow ID is 18516895) and easy to guess. So I can just try passing some random numbers/string and might be able to make requests on behalf of someone else. So JWTs are mostly used for Authorization and Information Exchange.
Also checkout: Introduction to JSON Web Tokens
But suddenly I want to raise my stack overflow score. Then just checking the token is not enough for server I guess. right? How do you prevent in this case?
Allowing users to update their score doesn't seem to be a good idea. Instead the score should be done totally on back-end and can be triggered by any action such as user winning the game.
Take Stackoverflow for example, only the person who has asked the question can mark any of the answers as accepted. This is authorization. No one else is allowed to do so. After an answer is accepted, the system updated answerer's score (reputation), so there is no API request that is made from client side to increase score.
The flow could be like:
Questioner accepts an answer
Verify JWT, marked as accepted if owner of question
Increase score (reputation) of answerer
Adding to another case of single player game Tetris where the user directly needs to update server for a win and earn points as discussed in comments, it might be best to send every move to server and run all game win logic on backend instead of checking for win on client and letting users hit a /win API over and over again. If the game is completed, then credit points to user if won.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
We are building a mid-sized project. We have React UI and Express backend. For authentication, when user submits his credentials, there is a POST call to backend to authenticate user.
The problem is, we can clearly see the user input in-network calls. This might be a problem. Is there a way to hide this information? How is the industry tackling this situation? Is this fine? I've seen Twitter's authentication flow. It's a bit different. I'm unable to see the data I submitted.
It's completly normal to have an POST request with a content of
{
username: "myName123",
password: "myPassword456"
}
You can see this in almost every service, which requires authentication.
When you do this, make sure your communication with the client is encrypted (HTTPS) so that a man in the middle can't read it.
Don't trust the user - clean the input from stuff that should not be there.
Encode / hash the input by adding something to mix up the logic.
Decode / dehash and verify.
When you encode something with built in feature - like base64 then add some variable to the string that makes it more random.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Lets say I am making a web app (e.g. mean stack) for an exhibition, i want to ensure my server only take requests from users who are really in the venue, how can I do it? What are the common attacks?
The short and generic answer is you cannot really do this, but read on.
The question you need to answer is against what do you want to protect your app, what is the threat that you are trying to mitigate.
You can build any protection in your mobile app (like for example the one in the other answer), but keep in mind that the client is fully controlled by the user. For example the user may fake location coordinates for the app (see Pokemon Go), it is very easy to do either in an emulator or an actual device. Or even easier, the user can just make requests from an arbitrary source, not your application. A server request would have to contain the location of the user - but the user can send whatever he wants. So in short, anything on the client is fully controlled by the user.
So this leads to server-side protection as the only way for an actually secure solution (one that is reasonably hard to circumvent). The only source where your server knows where physically the client is if the client tells the server - but we have seen above that is unreliable.
However, there is one thing a client can't reasonably fake (at least not easily), and that is the client IP address. So pretty much the only thing you can do to prevent users not being present at a venue from using your service is to lock it down on the network level, for example your API server should only be accessible from the IP range that the wifi at the venue provides (presumably a local address range, or if your API is in the cloud then the public IP address or range of the venue).
Save your venue location in your app or on your server side. Then try keep track of users by getting their location around 100 ms or a Radius which you choose.
add CoreLocation.framework to BuildPhases -> Link Binary With Libraries (no longer necessary as of XCode 7.2.1)
import CoreLocation to your class - probably ViewController.swift
add CLLocationManagerDelegate to your class declaration
Add NSLocationWhenInUseUsageDescription and NSLocationAlwaysUsageDescription to plist
init location manager:
locationManager = CLLocationManager()
locationManager.delegate = self;
locationManager.desiredAccuracy = kCLLocationAccuracyBest
locationManager.requestAlwaysAuthorization()
locationManager.startUpdatingLocation()
get User Location By:
func locationManager(manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) {
var locValue:CLLocationCoordinate2D = manager.location.coordinate
print("locations = \(locValue.latitude) \(locValue.longitude)")
}
Do have a look into thisTracking Location
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
I have a problem with Bonita that I've tried to work around without success. I am authenticating with CAS into Bonita, Alfresco and Liferay; the first time I am authenticating with CAS everything works fine, but when I logout from Liferay (which should then logout automatically from CAS), the current Bonita session is not terminated. The next time I login with CAS the Liferay and Alfresco sessions are correct (they belong to the new user), but the Bonita session doesn't change (the old user is still connected). Did anyone encounter this issue, and if yes, what could be a possible correction for this?
Any insight regarding the matter would be very appreciated, thanks!
I have managed to do this after a couple of difficult attempts to understand what the problem is. Apparently, there was a problem with the session cookie created by Bonita: the cookie JSESSIONID with the path "/bonita" was not destroyed when CAS destroyed its session and somehow its presence stopped it from being recreated. I have changed the Bonita cookie name to be different than JSESSIONID, because there were other cookies with that name in the browser and I changed the path of the cookie from "/bonita" to "/" in the file context.xml of Bonita. Then I have added javascript code to eliminate this cookie each time the theme of Liferay was reloaded (on page refresh), thus ensuring that the old cookie was destroyed. Every time after, when the Bonita url is visited the updated cookie is recreated from the new CAS session and everything seems to work fine. A better approach would be to destroy the cookie in the CAS logout jsp page, but I didn't manage to do it like this.