-
Notifications
You must be signed in to change notification settings - Fork 6
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
Credentials issue with destination #4
Comments
Hi Holger @hschaefer123 Thanks for raising this issue and providing your findings! I will look into it and see what I can do to add support for default-env.json. Cheers, |
Hi Holger @hschaefer123 I looked into this today, tested it locally while connecting to SCP Destination. See my answer to the below question: My guess is that your use case is slightly different -- am I right? You want to avoid putting the credentials on the CDS configuration (in package.json), is my assumption correct? |
Hi Jhodel, Since package.json it in git commit, this is dangerous. I think remotely in CF, your code also works as expected. Locally, i am trying to figure out some pros/cons for different solutions! With the above setup, cds
cdse
cloud sdk using vdm
cap using cloud sdk generic rest client
BTW: did you also thaught about utilizing the executeHttpRequest? Please let me know, if you need more input. Best Regards |
Hi Holger @hschaefer123 I tried cloud sdk before but it got stuff there that I didn't find in sync with CAP -- like:
So your suggestion is to configure the credetials in default-env.json like below: {
"VCAP_SERVICES": {},
"destinations": [
{
"name": "udina_commerce_shop",
"url": "http://xxx.sap.de:1234",
"username": "xxx",
"password": "yyy"
}
]
} I suggest to keep the default-env.json to SAP and use .env file for CDSE instead. {
"cds": {
"requires": {
"API_SALES_ORDER_SRV": {
"kind": "odata",
"model": "srv\\external\\API_SALES_ORDER_SRV",
"credentials": {
"url": "http://xxx.sap.de:1234",
"username": "{{API_USERNAME}}",
"password": "{{API_PASSWORD}}"
}
}
}
}
} The values in here will get replaced by the one configured on .env file: "username": "{{API_USERNAME}}",
"password": "{{API_PASSWORD}}" Your thoughts? |
Hi Jhodel, I will explain it a little bit more. The original package/cds contains packages.json | .cdsrc.json
This will be the productive setting, that will be deployed to CF. Inside the credentials will be at least the destination name, and if the destination names is not used, CAP will use Local Testing I think you formerly also commented it out like "_destination" for local testing, but using it the productive way, you do not have to touch the packages.json for local development. For local testing, only the node env setting is relevant. You have two option:
All this kinds are supported by CAP. I am prefering default-env.json, because the settings can be easily declared as an object. default-env.json
.env
This is the same behavior, like the @sap/approuter is working
CAP is just accessing Would be great, if you would use the same logic chain, like CAP/Destination service:
Anyhow which env injection you prefer, all of them should/can be supported, because you will have them availabe inside Also What do you mean? Best Regards |
Hi Holger @hschaefer123 I think I get what you mean. However, I don't see from your approach that you attempted to use CAP's concept of configuration profiles. Configuration profiles keeps your local settings separate from your productive setting. See example below: If you use this approach then there shouldn't be any problem with using .env file. I'm trying to steer clear from using default-env.json because that approach is trying to mixin with the CF concepts wherein the introduced property destinations is practically a foreign entity. |
Hi, cds-runtime/lib/rest/service.js const _checkProduction = destination => {
if (!destination && process.env.NODE_ENV === 'production') {
throw new Error('In production mode it is required to set `options.destination`')
}
} also handles this and later on if (!this.destination) this.destination = getDestination(this.model, this.datasource, this.options) I do not do something specific, because this is supported out-of-the-box by cap. Generally i am trying using as much as possible from the core, but in this special situation, i see the need for your little nice CDSE project ;-) The other way around would be the need to extend the orinal CAP to support CSRF for POST like you did. In my scenario, i do not need to differ between production and local, because cap supports it directly. I just need to hav a different local env to overcome destination and use locally defined one. But what would be the difference in your upper config? Also i am using the same approach in approuter, see
The reccomendations here are
Or the @sap/xsenv see section local usage
But it depends on you, if you will add this compability to sap cap cds.connect.to. Finally i choosed default-env.json, because it is used most common among libraries (one file fits all ;-) Best Regards |
Hi Jhodel,
i was just externalizing my
package.json
while using a default-env.json to externalize the credentials
default-env.json
if i am using your
const cdseSrv = await cdse.connect.to('API_SALES_ORDER_SRV');
i got errors
I think, you currently do not take care of the env destination settings.
Running with inline credentials and commenting "_destination" service is working, but i want to use it the sames way like the productive szenario.
Would be great, if you would support local destinations inside env for local testing.
Also this way is more secure, because default-env.json is ignored by git.
BTW: Very nice implementation for CAP! ;-)
Best Regards
Holger
The text was updated successfully, but these errors were encountered: