Affected version - 2.0.37.
Not reproduced at 2.0.35 version.

When I making a request, e.g. accounts.login I getting an error:

Missing required parameter: ApiKey

Running with NODE_DEBUG=request showed:

REQUEST { method: 'POST',
   form: 
    { loginID: '[email protected]',
      password: 'xxx',
      format: 'json',
      secret: 'xxx',
      userKey: 'xxx' },

There is no API key indeed.

I think it happens because of this commit:
45a6b81

            if (isAdminEndpoint && !userParams.apiKey && this.apiKey) {
                requestParams['apiKey'] = this.apiKey;
            }

What if isAdminEndpoint === false ?

Hi Guys! Please help or advice. I'm trying to add a new provider Line, configured Line in a gigya console under Providers Configurations section(App ID, Secret Access Key). Using method with params gigya.accounts.socialLogin({provider: "line", keepLogged: true}).

On click I see https://take.ms/WtURX, but when I'm typing a correct email and password always see the text The email address or password you entered doesn't exist or is invalid. Please also ensure that you have enabled "Allow login" on your smartphone as shown below: Settings > Accounts > Allow login

Settings > Accounts > Allow login is active https://take.ms/eFtnq

https://take.ms/d40Ia Email and password are correct because I able to login with these credentials in Line mobile, desktop apps.

Tried the same flow on package versions 3.0.1, 2.0.33. Please help.

Issue:
When bundling a project that uses gigya, the node_modules directory is not included in the project, so there is no reference to the cacert. This causes the failure below:

Error: ENOENT: no such file or directory, open \'/assets/cacert.pem\'' } 

Solution:
The CaCert needs to be bundled with the dist, and not using a relative path to import it.

Hello
The api client works perfectly when used in a CLI script, but never returns nothing when used as a lib in my app.

Beyond the starting of the request in screenshot, I can't even console.log stuff

Tested on osX and on an EC2 machine.

Could it be due to my configuration ? linux packages missing ? I have received no warnings at all and it works well on a CLI environment

Hi,
I wanted to use gigya on client side in Angular project.
I didn't find the accounts.showScreenSet() method so I just referred to the Gigya.request('accounts.showScreenSet', {...}).
But what I get is this error:

EXCEPTION: Uncaught (in promise): TypeError: fs.readFileSync is not a function
TypeError: fs.readFileSync is not a function
at getCertificate (http://localhost:4200/vendor.bundle.js:133782:26)
at http://localhost:4200/vendor.bundle.js:133795:17
at new ZoneAwarePromise (http://localhost:4200/polyfills.bundle.js:745:29)
at Gigya.exports.httpRequest (http://localhost:4200/vendor.bundle.js:133790:12)
at Gigya. (http://localhost:4200/vendor.bundle.js:96419:51)
at step (http://localhost:4200/vendor.bundle.js:96286:23)
at Object.next (http://localhost:4200/vendor.bundle.js:96267:53)
at http://localhost:4200/vendor.bundle.js:96261:71
at new ZoneAwarePromise (http://localhost:4200/polyfills.bundle.js:745:29)
at __awaiter (http://localhost:4200/vendor.bundle.js:96257:12)
at Gigya._request (http://localhost:4200/vendor.bundle.js:96373:16)
at Gigya. (http://localhost:4200/vendor.bundle.js:96364:44)
at step (http://localhost:4200/vendor.bundle.js:96286:23)
at Object.next (http://localhost:4200/vendor.bundle.js:96267:53)
at http://localhost:4200/vendor.bundle.js:96261:71

I didn't try to investigate it but by the error message it's obvious that this lib is designed for node applications.

The question is: is it possible to configure it somehow for client application? Or maybe there is already some other package that I could use in a Angular application? Currently all I have is just the Gigya's SDK available via CDN.

I am using node version 4.2.3, it is a legacy application which has been using this version since a long time and has been passed on to me.
When I try to use node version 4.2.3, it throws UNABLE_TO_GET_ISSUER_CERT_LOCALLY error while initiating registration. Though it works fine with v4.9.1 and also v8.11.1 as per my testing

I tried to use validateUserSignature to validate the signature from my login response with no luck.
The UIDSignature response from gigya and the signature generated by calcSignature is not equal.

Thanks

Calling gigya.ds.store({ ... }) returns error:

Gigya API ds.setSchema failed with error code 403005 and message Unauthorized user

Hey! Thanks for all your hard work on writing Gigya wrapper for node.js ! :-)

I think will be good to support promises for example

gigya.socialize.getToken(params)
  .then(loginUser)
  .catch(errorHandler)

When I try to call the servers, using NotifyLogin, I get the error :

403003 Invalid request signature The request is not signed with a valid signature. Please refer to Signing requests for more details.

I got a response from Gigya, stating:
"
It's likely because the timestamp on the server is off.

Easy solution: when constructing the Gigya object, pass "true" as the 3rd parameter to use HTTPS mode (which doesn't require a signature).

var gigya = new Giga('apiKey', 'secret', true);
"

When I add the 3rd param 'true', as recommended, Gigya behaves properly.

This should, however, work in both configurations, which is what this bug is about.

Hi,

I'm using this library on my lambda function, however, I'm getting this error.

{
  "errorMessage": "getaddrinfo ENOTFOUND idx.eu-west-1.gigya.com idx.eu-west-1.gigya.com:443",
  "errorType": "Error",
  "stackTrace": [
    "errnoException (dns.js:50:10)",
    "GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:92:26)"
  ]
}

I would like to apologize in advance if I'm using it wrong. I tried to debug it myself but it seems to be written in typescript.

const {Gigya} = require('gigya')

const gigya = new Gigya(
    process.env.GIGYA_API_KEY,
    process.env.GIGYA_DATA_CENTER,
    process.env.GIGYA_USER_KEY,
    process.env.GIGYA_SECRET_KEY
);

const job = await gigya.idx.search({query: `SELECT * FROM idx_job_status WHERE id = "${jobId}"`});

What is this feature?

Support for fidm.oidc.op.getMetadata

Version

v3.0.2

Issue related

Issue #51

Pull request

PR #52

Note: Apologies for raising this as an issue. I'm just keen on using this in our codes. Thank you so much.

What does it do?

It's an endpoint that allows OP to pull the OP metadata which contains different endpoints such as authorize endpoint, token endpoint, userinfo endpoint, introspect endpoint and most importantly the JSON web keys.

Why do we need it?

It is necessary so that we are able to pull the latest jwks when validating id_token. It's stated in the document that it could change without prior notice so it would be better to get it from the source rather than having it offline.

Source: https://developers.gigya.com/display/GD/Validate+A+JWT+from+SAP+Customer+Data+Cloud

Public keys are subject to change without warning for security reasons. Recommended best practice is to check the keyid returned in the JWT header against the kid (Key ID) of the public key you have stored from accounts.getJWTPublicKey, or that you received from the OP, and if they do not match, you must update your public key using accounts.getJWTPublicKey or contacting the OP.

Workaround

As a workaround, I do:

gigya.request('fidm.oidc.op.getMetadata')

Note

This endpoint is not listed in the documentation for some reason.

got to do the lite-registration like this

const initResponse = await gigya.request("accounts.initRegistration", {isLite: true}) as any;

Hey,
I'm developing a new app and I need to use the following methods which are missing from the api:
admin.getGroups
admin.getACL
admin.setACL

Thanks,

I cant init gigya. i follow ur steps on a vue js project.

I have the next error on deploy:

Do you have some idea about wht am doing wrong ?

First of all, thank you for the work done! This is a very comprehensive way to access Gigya library using TypeScript!

Nevertheless, I noticed this project has no commits since August 2020 and some interfaces are outdated. Is there any intention to update this library to stay in synch with Gigya API?

https://developers.gigya.com/display/GD/accounts.resetPassword+REST

You are required to pass only one of the parameters either loginID or passwordResetToken.
If passwordResetToken is passed then the newPassword parameter is also required.

and currently interface looks like this:

export interface AccountsResetPasswordParams {
    loginID: string;
    passwordResetToken: string;
    newPassword: string;
    secretAnswer: string;
    securityFields: string;
    email?: string;
    lang?: string;
    sendEmail?: string;
}

so creating API action like this is not possible:

const options ={
loginID: '[email protected]',
sendEmail: false,
}
const token = await gigya.accounts.resetPassword(options);
if (token.statusCode !== 200) {
      throw Error('message');
    }
const responseReset = await gigya.accounts.resetPassword({
      sendEmail: false,
passwordResetToken: token.passwordResetToken,
newPassword: password,
    });
if (responseReset.statusCode === 200) {
      return 'success';
    }

Could you please update interface?

Hi I recomend remove the word Unofficial. This word scared some people.

You exaplain this in Usage.

This is an unofficial SDK for Gigya's REST API. Please do not contact Gigya support with questions or concerns about this SDK. For any issues, please make an issue on GitHub.

I know this package its't supporter by gigya support team.
You can explain this with others words like this.

This is an open source SDK for Gigya's REST API. Please do not contact Gigya support with questions or concerns about this SDK. For any issues, please make an issue on GitHub.

Hi guys,

this library ask api_key and secret_key but this approuch is secure ?

please let me know.

Hi Scott,

when installing the gigya sdk it fails installing the asn1js package from http://sinopia.gigya.net:4873/yargs-parser/-/yargs-parser-20.2.9.tgz

Currently, the REST API calls are not signed. Secret is sent as part of the payload.

Recently ran into an error while using the SDK, which said that the certificate is not valid and caused requests made through the SDK not to go through - Error: code: 'SELF_SIGNED_CERT_IN_CHAIN'

This can be resolved in replacing the certificate (assets/cacert.pem) the package uses locally with an updated certificate from SAP themselves - https://github.com/SAP/gigya-python-sdk/blob/main/cacert.pem as an quick solution.

Hopefully someone can create a pull request, and publish an updated version of the package.

Hello, @scotthovestadt. I found that gigya library doesn't support acounts.tfa.{method} requests. Could you add this requests to the library?

Thanks.

As an example https://help.sap.com/viewer/8b8d6fffe113457094a17701f63e3d6a/GIGYA/en-US/559574624b634e5a955e0f7eeba01c07.html
resetPassword allows you to send a parameter:

sendEmail | Boolean | The default is true . When set to false Gigya does not send the password reset email to the user, instead, the passwordResetToken and the list of valid email addresses are returned in the response of this method (see passwordResetToken and emails fields in the method response below).

then when calculating signature here:

code snippet to reproduce behavior:

var strictUriEncode = require('strict-uri-encode')
var requestParams ={
   loginID: '[email protected]',
   sendEmail: false,
   apiKey: 'api_Key',
   format: 'json',
   userKey: 'user_key',
   timestamp: 1639676755638,
   nonce: 1125281701940
 }
var queryString = Object.keys(requestParams).sort().map(function (key) { return key + "=" + strictUriEncode((requestParams[key] || '').toString()); })
//outputs:
[
  'apiKey=api_key',
  'format=json',
  'loginID=bmxpiku%40example.com',
  'nonce=1125281701940',
  'sendEmail=',
  'timestamp=1639676755638',
  'userKey=user_key'
]

// because:
> strictUriEncode(false || '')
// returns:
''

In relation to #59 -> I'm creating an issue on GH only to add a comment in the codebase of why I pass secret in URL as per gigya documentation:

When making the API call over HTTPS, you may pass the secret parameter. In such cases, the timestamp , nonce and sig parameters are no longer required.