Can't find a way to to upload file directly to bucket instead of submiting file to PHP backend and then forwarding it from backend to bucket.
Is there a way to do this with 2-legged token?
There is but for security reasons the recommended approach is to upload from client to backend and from backend to Forge. The reason is to avoid sending a token with data:write or data:create privileges to the client, which would allow an attacker to mess up with the data present on those buckets.
If you want to do it from client however, the only thing you need to do is to generate a token from your backend, expose an endpoint for your client to access it and perform a REST call from the client using the token and that endpoint: PUT buckets/:bucketKey/objects/:objectName
Related
I am trying to achieve the following the scenario but ending up as 403 response.
Client -> sends Cert A -> API Management -> Forwards Cert A -> Backend API (Azure Api App) -> Authenticates the certificate.
Is there is a way to configure API management to forward the incoming certificate to the backend API?
I tried various transformation policies on the incoming request but none of the options worked.
Please suggest.
This is technically not possible since client certificate's private key is never transmitted over wire. So there is no way APIM could use it to authenticate to backend. Even more so since there is no affinity between client connection and backend connection in APIM. Your best option is to send client certificate information in a custom header. You can use ser-header policy to set it at APIM level along with policy expressions to extract client certificate information from request.
With the new authentication-certificate policy (learn.microsoft.com) you may return the certificate as a byte[] coming from a separate send-request response-variable and use it as follows:
<authentication-certificate body="#(context.Variables.GetValueOrDefault<byte[]>("byteCertificate"))" password="optional-certificate-password" />
You could store the password as a secret named value or even get it from the KeyVault by using this snippet:
github.com/Azure/api-management-policy-snippets
We have configured the ELB with 2 server for the Web API. Updated the MachineKey in both the server to be same.
When the Reset Token password/Confirm password is created from server1. The Url is sent to the User Email when the Verify token call is Made the Server1 Verify the token successfuly, But if call is sent to the Server 2, Server 2 always returns Invalid Token. Do i need to make any configuration chanages other than the Machine Key.
You need to make sure that the all the request belongs to one session goes to the single backend.
In order to do this enable session stickiness on the ELB. This will make sure that request always gets routed to the same backend.
On Classic Load balancer : https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html
On Application Load Balancer : https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#sticky-sessions
I'm attempting to understand how spring boot uses http sessions to manage the oauth authorization code flow.
I understand that after the user submits their credentials via the /login form spring will persist the authentication object so it can be retrieved when the browser is redirected to retrieve the authorization code.
What I dont understand is if the browser needs to sends jsession cookie to the server or http basic authentication header when invoking this flow.
For example if I wanted to initiate the flow manually via curl do I need to specify any special headers ?
It doesn't use HTTP sessions to persist it, the client ID and authorisation code (the code that's passed back to the client app after the user authenticates) is used to identify the authentication object. The authorisation code is then used to obtain the access token.
So:
The client app redirects to the auth server, passing in their client ID.
The user authenticates with their username and password on the auth server , which stores the authentication against the code and client ID and passed the authorisation code back to the calling app as a request param on the redirect URL.
The client app calls back to the auth server, authenticating with it's client ID and secret and passing in the authorisation code. This is then swapped for the access (and possible refresh) token.
If the app needs the user details, the client app calls the user details endpoint authenticating with the access token it now has.
I have exported my data from Parse.com but the passwords are encrypted using bcrypt. I will be storing the data in a MySQL database and users will connect over a simple RESTful API. Assuming I capture the username and password, how do I check this matches the stored password?
I'm going to go out on a limb here and say that there is no way to decrypt the passwords once they're encrypted with bcrypt - this would be a massive security hole for a myriad of reasons. Here are a couple of links that hint towards this being the case:
https://www.parse.com/questions/encryption-decryption-techniques-provided-by-parse-for-passwords-or-urls We use bcrypt internally to store passwords. However, we don't expose the encrypted version of the password in our API, so you wouldn't be able to decrypt it anyway.
How to send Parse user's password to external API Request?
https://stackoverflow.com/questions/35593429/get-parses-user-password-in-decrypted-format
In short, you're going to have to communicate out to your users that they'll need to change their password (or at least confirm it) when you migrate them over to the new service.
I'd suggest a workflow like so:
Inform users that their password needs to be confirmed/re-validated. Up to you whether you inform them that it's due to a data migration, but I usually air on the side of disclosure and honesty. You could do this on a per-user basis or send out a bulk communication.
When a user goes to log into your app next, prompt them to validate their password (or change it). Use the Parse SDK to validate the password, and if authentication is successful, re-encrypt the now-known password using a crypto solution of your choice, then store it in your new BaaS/dB.
If the user cannot validate their password or does not remember, use an email or 2FA verification process to reset their password and store it in the same manner.
It is impossible to decrypt the passwords.
I strongly recommend you to use parse.com database migration tool to export your data to an external MongoDB. You can use Parse Server to serve the RESTful API. It can be easily done by hosting your own self-hosted server or a Parse Hosting solution like https://www.back4app.com
See all options in the link below:
https://github.com/ParsePlatform/parse-server#parse-server-sample-application
I'd like to use realtime API with server side OAuth2 authentication flow. This would improve the user experience as it forces the user to grant access only once.
Is there a way to "inject" the server side token into the realtime API on the client side?
What Drive API uses to authorize user is access_token. After all OAuth process, you will save credentials which will provide you access_token on server side. You can pass this access_token from server side to client side and use it in javascript client. However, you should make sure that access_token is sent securely to client side, over SSL, or otherwise, it will make serious security issue.