-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
[2.3.2] Always unauthorized using sessionToken from user (request.user) #3395
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@contervis do you have any CLP (Class Level Permissions) configured on this class? |
@natanrolnik The specific class involved in the issue has public READ and WRITE access level. |
I have the same problem since I attempted to upgrade yesterday. Last known good version for me (using sessionToken) was 2.2.23. |
Also having the same problem after upgrading this morning. |
Can you provide the logs when runnjngn with VERBOSE=1? |
We are also having this issue. We get the same error when running It seems to be an issue introduced in |
as much as I would like to help, can you please provide the logs when running the server with VERBOSE=1 please? Without it, there isn't much to be done. |
Yes, of course, sorry. This is the output when running
Please let me know if you need anything else. EDIT: tried different versions more thoroughly and discovered that the error first appears in version 2.2.24. |
This is now solved! Saw this issue #3577, and I had done something similar. Previously I had configured my cloud code with I suppose this behaviour was introduced in e788d49 |
so @johanarnor everything works for you? |
@flovilmart yes! |
That's great to hear! @contervis, I'M not sure if you jumped between 2.2.23 and 2.3.4, but can you try it out? |
I can confirm that this does seem to be an error with the logic introduced in e788d49 When I upgrade my project from 2.2.23 to 2.2.24, some cloud code using
As far as I know the Thanks a ton @johanarnor @contervis and @oliverchoy et all, this was annoying to debug and you guys helped a lot! |
The change in 2.2.24 is to enforce key security correctly. Previously if any key was omitted then none were checked, which removed the point of having keys and which led to an undesirable workaround of having to specify unused keys if you wanted key security. You should be able to remove all client keys from config if you want to disable key security, although I've not tried how this works with cloud code. This change does seem to cause a lot of issues so perhaps the documentation needs an update? |
Yeah, I think we should just update the documentation if that's the case, so people are aware that they'll need |
@steven-supersolid @artonragsdale I'm using cloud code and have removed all my client keys from the parse-server config. I using I can supply it as well without any affect, so I guess it is just ignored in the request on the server. |
So my understanding at this point is If you want to use cloud code, you can either: You cannot use any client keys without configuring Does that sound right? |
Yes, that sounds right. |
Yes. And can confirm @johanarnor final point: values for keys that are not configured in the constructor are also ignored. |
Let me understand, in this scenario can I continue use the same code just by adding the |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Issue Description
My instance of Parse Server always error out with error "ParseError { code: undefined, message: 'unauthorized' }" when using find({sessionToken: }). The session token is retrieved with "request.user.getSessionToken()".
Steps to reproduce
Expected Results
No error
Actual Outcome
ParseError { code: undefined, message: 'unauthorized' }
Environment Setup
Server
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 6
On-line CPU(s) list: 0-5
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 6
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 63
Stepping: 2
CPU MHz: 2499.980
BogoMIPS: 5001.29
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
NUMA node0 CPU(s): 0-5
Database
The text was updated successfully, but these errors were encountered: