When does IDN apply URL encoding and can that be changed?

We’ve run into an issue with one of our connectors in which our oauth token request API calls are getting a 400 error.

After talking to dev support from the application, I was informed it’s because the request is getting mangled by URL encoding before hitting the endpoint. Is there a way to not have this applied to the outgoing request?

I think this might be a recent change.

Our Zendesk integration cannot aggregate accounts anymore because the account filter field is also getting URL encoded since the 8th of August :upside_down_face: role[]=admin&role[]=agent ends up as role%5B%5D%3Dadmin%26role%5B%5D%3Dagent - you can see the outgoing call from cgg.log

I’ve opened a support ticket as well but no luck with that yet (albeit it’s been just 2 days since I reported it)

Is your integration using a Sailpoint provided connector as well or is it web services?

We are!

Good news though I actually just solved this one yesterday, you can add this filterString:
“!((role == "agent" || role == "admin"))”
to your connector and it will still filter the end-user accounts out.

Bad news is that since it’s being filtered on the IdentityNow side versus the Zendesk side it takes MUCH longer to filter.

1 Like

Thank you for the suggestion - seems to work, aggregation’s been running for 14 minutes now. Which is considerable longer than it should take, like you suggested.
@colin_mckibben is there any way we could… highlight this issue? It seems to me that this might have a pretty big negative impact

@M_rtenH can you DM me the ticket number?

I’d like to follow up that this can also be fixed by migrating the Zendesk filtering to the query parameters versus wherever IdentityNow puts it now. Unfortunately since we can’t edit the calls that OOB connectors use we can’t implement this fix ourselves.

@M_rtenH @jbogash are you only noticing this URL encoding on the Zendesk connector, or other connectors as well? If so, which connectors?

Just Zendesk so far. I could copy over what their dev support told us if that would be helpful.

Also just Zendesk, but we aren’t using that many SP provided connectors either.

Good news, engineering identified the issue and will be working on it soon.

Engineering has just applied a fix for this. Once your VA has been upgrade to the CB 111.0 build, the URL encoding will work as it used to.

1 Like

Hi @colin_mckibben , I am also Facing same issue with Ventiv Application, when I set Skipencoding variable as true, then I am unable to aggregate the Data, its only give Success result and not giving any Account Details, Even the same Thing working fine in Sailpoint IIQ. Raised a ticket but no inputs yet .

Thanks

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.