It looks like OneLogin add #error=xxxx in place of ?error=xxxx when something is wrong. I do not have this issue when no error.
I wanted to warn user about configuration error. Unfortunatly because of the '#' my server base on libmicrohttpd does not parse correctly the url query.
any idea ?
https://localhost:1234/sgate/onelogin/login#error=unsupported_response_type&error_description=unsupported%20response_type%20requested&state=2f886384-4c57-4c9a-a933-ef989bf26385&ol_oidc_issuer_url=https%3A%2F%2Fiot-bzh-dev.onelogin.com%2Foidc%2F2
Related
I am trying to post a request to add a row in sheety. I am facing two problems.
1 st part -
**A valid 'Authorization' header is required to access this API." **
What should be included while giving header, api_key,api_id,Content_type,Authorization and way to write the header???
2 nd part -
**
add_row_url f"https://api.sheety.co//myWorkoutsSelf/workouts"**
What should be added in the url above the username or the url generated by sheety website???
I humbly request anyone working in sheety to help me out i have been stuck in this for too long.
Thanks
To get a proper syntax and help regarding the headers and URL
I am sending query String as:
https://prod-17.westindia.logic.azure.com:443/workflows/f3b63b086e61420e8d76b7478f4b3e39/triggers/manual/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=nESqZWY2NyAKKhCkaM0VnfenHuTqi1NSBjJdl9M5jNA&UserName=SecretName&Password=Nikita#123
I want to extract UserName in logic app. For that I have used Compose connector and use following statement in expression.
coalesce(triggerOutputs()['queries']?['UserName'] , 'blank')
I have tried this to:: triggerOutputs()['queries']?['UserName']
But I am getting one single blank space appended in front of UserName in output. Due to which, my condition is becoming false even if UserName is correct.
How to remove this extra space which is unnecessary appending to front.
HTTP Connector Output as :
In this scenario , password is working fine. As below is output:
You should use the trigger output and you should not use the Coalesce expression.
My URL have some params, so i use friendly URLs to solve that ugly URL liferays generates by default.
couple of this params sometimes are empty, that mean its no needed, but other times give me some ID i use for a query.
Example param not null:
https://myliferay.com/example-portlet/-/example-portlet/search/idTable-7
//it works
Example null param:
https://myliferay.com/example-portlet/-/example-portlet/search/idTable-null
//it works
With null param it works, but i dont like to see a null on my URL.
I want something like "":
https://myliferay.com/example-portlet/-/example-portlet/search/idTable-
//Doesnt work
But it doesnt work, its like the URL doesnt match the friendly URL pattern when a param its empty.
<route>
<pattern>/search/idTable-{idTable}</pattern>
<generated-parameter name="idTable">{idTable}</generated-parameter>
<implicit-parameter name="p_p_lifecycle">0</implicit-parameter>
<!--more implicit params-->
</route>
How can i specify optionality of a parameter?
Its like all vars of friendly url use a regex. You can change/override this regex like this: {idTable:\d}
<route>
<pattern>/search/idTable-{idTable:.*}</pattern>
<generated-parameter name="idTable">{idTable}</generated-parameter>
<implicit-parameter name="p_p_lifecycle">0</implicit-parameter>
<!--more implicit params-->
</route>
i used .* as regex for 0 or more characters, but i dont know if it will bring me problems later. If anyone knows why is not a good idea to use that regex comment it please.
Upgraded the regex with \d* to search only digits or empty: {idTable:\d*}
Info: Making URLs friendlier 7.0
I setup OpenSips 2.3 proxy server, so any call come on server, my script grabs sip URI from DB, and forward call to that uri. When I get value I used AVP to get value and save it in $avp(didnumber), if I use rewrite with manually specifying uri it is working, but when I grab this value from DB and than assign it, it is not working in rewriteuri() method.
$ru = "sip:"+$avp(didnumber)
if I write
rewriteuri("[$ru]")
it throws following error
ERROR:core:parse_sip_msg_uri: bad uri <[$ru>
ERROR:tm:new_t: uri invalid
ERROR:tm:t_newtran: new_t failed
I think this method does not accept normal variable so I added quotation to make it string variable, now it shows fine on log but seem I have to convert variable using AVP or transformation, I tried many syntaxes but still could not do it. Please suggest.
rewrite_uri() has been deprecated in favour of simply using $ru. Your R-URI already gets completely rewritten by this statement:
$ru = "sip:" + $avp(didnumber);
However, note that the above is incorrect, since you do not supply a "hostport" part to the uri, according to the SIP RFC 3261:
SIP-URI = "sip:" [ userinfo ] hostport
uri-parameters [ headers ]
The parser will likely report an error. There are two fixes for this:
either only rewrite the R-URI "userinfo" part, like so:
$rU = $avp(didnumber);
supply a destination hostname:
$ru = "sip:" + $avp(didnumber) + "#" + $var(destination);
Following from here, you can just t_relay() using your new R-URI.
EDIT: the OpenSIPS URI parser will actually tolerate a URI such as "sip:44776772882", but it will interpret the DID as a hostname, so the errors may start appearing later, should the script writer attempt to relay the message to the invalid "44776772882" hostname.
I have created a search form with get method. But when the url looks like this search.php?search[] or search?search[] (mod_rewrite) then I get a sql fattal error. It's passing an array and I want to avoid that problem.
my question is how do I redirect a person from that url to search.php
It sounds like you are directly passing the ?search[] query string variable into your SQL. mod_rewrite won't fix this for you... what if I decide to call your page with http://www.yoursite.com/search.php?search=;DROP TABLE users;? You simply aren't able to use mod_rewrite to predict all the bad kinds of input that a user can come up with.
Your code needs to be doing input validation and sanitization. You must assume that everything your script receives from the user is malicious and dangerous. That includes all data inside $_GET, $_POST and $_COOKIE.
The right solution here is to check that $_GET['search'] is a valid value to be passing to your SQL. Something like:
if (is_string($_GET['search']) && ! empty($_GET['search']) {
//escape the input properly using your database-specific method, e.g.:
$searchParam = mysql_real_escape_string($_GET['search']);
//run your query with the escaped data
}
At a minimum, that would ensure that your passed in search variable was not an empty string.