I'm just starting with Visualize.js to embedd jasper reports in a web page.
The first hurdle I ran into was authenticating to the server. It kept failing with "Authentication Error"
Okay, double check password, still no worky. After tracking the requests, and following the same steps to authenticate to the server directly, I discovered that when using visualize.js, it places the userID/pwd in the query string and performs a GET request. WHAT!? The problem was that I had special characters in the password that were not URL friendly. So, not only are they putting clear text passwords in the request URL, they aren't bothering to URL encode it.
I fixed it by encoding it myself, but this is blasphemy if you ask me. The userID and password will be in clear text in the request whether you are using SSL/TSL or not. Why on earth aren't they doing a POST?
So, the actual question: Is there a way to configure this to use POST instead of GET for the auth process?
This code does work, but again it is processed as a GET. The standard jasper login page does not do that.
visualize({
server: "http://myseverurl/jasperserver-pro",
auth: {
name : "myUserID",
password: encodeURIComponent("myWierdPassword**+&&&")
}
}, function(v){
alert('in callback');
}, function(err){
alert("ERROR: " + JSON.stringify(err));
});
Related
I want, for example, create a new client with admin user using admin-cli client.
The token generation works fine:
POST /auth/realms/master/protocol/openid-connect/token
b'username=admin&password=admin&grant_type=password&client_id=admin-cli'
Using that token I can also do some queries like when I need to get id of a client:
GET /auth/admin/realms/master/clients?clientId=my-test-cli
H' Authorization: Bearer xyz
H' Content-Type: application/json
However, when I want to create a new client-role or a new client I always get 400 error. I changed the log level to DEBUG in the Keycloak server but there is nothing useful there other than seeing logs that says the token successfully created.
POST /auth/admin/realms/master/clients/7534ac42-fe8b-4cde-b6c6-c385f4958e3b/roles
400 {"error":"unknown_error"}
I am using Python v3.x and Keycloak v14.0.0 running with JBoss Wildfly container.
Looking at admin user, it seems it has all the roles like admin, default-roles-master, create-realm and I don't see any role in the listings to assign because it seems it has it all. The same for the admin-cli client. The configuration of these two (admin user and admin-cli) are the default configuration that you start the server for the first time.
Do I need anything extra like creating a new role or something in order to get this working?
My payload to create a confidential client:
payload = {
"name": "Some Name",
"clientId": "some-name",
"secret": "some-name-secret",
"enabled": true,
"publicClient": false,
"authorizationServicesEnabled": true,
"redirectUris" : ["/*"]
}
I want to answer my question so that everyone with similar situation won't face the same issue.
Turned out that the payload that I was sending was not correct, thanks to #JanGaraj who pointed that out. But what I want to answer here is that how to find out what should the request body look like.
First, do not look at the documentation. In the documentation all the fields are optional and URLs are not correct either.
The simplest way is to start Keycloak server locally and log into the admin console in Firefox or Chrome, then press F12 to open Development Mode. Then you can see all the requests/responses in there.
For example, if you want to see how to update a role, go to Roles menu item on the main menu and select a role and update it. You can see PUT request with its body. That tells you what you need to pass in and to what URL.
As a hint, you don't need to pass everything when updating, normally only IDs and the fields that you want to update are enough.
I'm using the gmail api to create a Gmail manager to my application (php). I'm using the documentation provided by google for php and all works correctly except the dynamic emails. I was looking for information about it but I didn't find anything.
I show you some examples of how I see it in my application and how it should be.
Pinteres email:
To access AMP Email using GMAIL API, you should probably get the raw email. This can be done by passing the format as raw. The details are available in the official documentation here.
Example code will be somewhat like below in javascript:
function getMessage(userId, messageId, callback) {
var request = gapi.client.gmail.users.messages.get({
'userId': userId,
'id': messageId,
'format' : 'raw'
});
request.execute(callback);
}
Note: Please note that the response will be raw base64 data.
If you are unable get it here, then Gmail should probably be stripping off the same from the response for security reasons. AMP Email is considered sensitive.
We've been using LWA for a while successfully. We currently use the following options for "authorize":
scope: 'profile'
response_type: 'code'
popup: true
We use a redirect_uri instead of a callback function.
On the server we then request a token using the response code. All this worked without problems.
We now want to change from using a popup to a redirect to a separate page.
I switched popup to false, and updated the "return urls" on the LWA dashboard. Tthe sign in seems to work well, but once our "return_uri" is called, we fail to get the oauth token (we get 400 Bad Request) back.
From reading the docs, I can't figure out what else I have to change. Anyone have any ideas?
I figured it while rereading the docs. I needed to include a redirect_uri in when requesting the token from the backend. (And it should match the one used when calling authorize in JS SDK.)
Note: This is mentioned in the table of parameters, but the example is wrong and doesn't include it.
I'm trying to create a new warehouse from the Cloudant dashboard, but receive the following error message:
The Bluemix credentials you entered don't appear to be valid. Please try again.
I had a look at the network traffic and noticed the following url:
https://...cloudant.com/_api/v2/partners/dashdb/warehouse/account?
bluemix_username=...&bluemix_password=...%26...
I checked my password and there was an ampersand in it & which looks as though it has been url encoded.
Do I need to remove any characters from my password that could get urlencoded to a different value?
I removed the & character from my password and I was able to enter my credentials without problem.
I'll leave this Q&A here in case any one else experiences this issue.
I have rather special need in login to vBulletin not from forum directly. I looked through topics by searching "vbulletin login", but found nothing.
So here's the structure.
domain.com - main site, access is
restricted by ip range
domain.com/forum/ - vB with cookie's
host set to .domain.com, of course
it's also restricted by ip
extra.domain.com - secondary site
which is available to almost anyone
('almost' includes users of vB
created manually via ACP)
As for now users already authenticated at domain.com/forum/ are recognized both at domain.com and at extra.domain.com.
So the problem is to login from extra.domain.com to domain.com/forum/
However i can't just post entered usernames and passwords to forum because of ip restriction. As I get it, there should be some wrapper, which will do all the login procedure via cURL or somehow, get all the cookies and then return them to user.
First of all, please tell me if I'm on a right way in my thoughts? Also are there any other ways to complete task without having to spend hours with HTTP sniffer? I mean are there any SOAP plugins for vB auth from trusted domains? Forum version is 4.0.8
Does the code on the secondary site have access to the vBulletin code & database? If so, you can handle vBulletin logins in PHP like so:
chdir('/directory/where/vbulletin/is');
require_once('global.php');
require_once(DIR . '/includes/functions_login.php');
// Check for too many login attempts
$strikes = verify_strike_status($username, TRUE);
if ($strikes === FALSE || $strikes >= 5) {
// TODO: Your error handling here
}
// Attempt authentication
if (!verify_authentication($username, $password, '', '', TRUE, TRUE)) {
exec_strike_user($username);
// TODO: Handle bad username & password here
}
// Clear records of previous bad logins
exec_unstrike_user($username);
// Create a new session
process_new_login('', TRUE, '');
The code above should work with vBulletin 3.8.x, but from what I remember of 4.x it shouldn't take much tweaking to make it work with 4.0.8.
Set the 5th parameter to verify_authentication to false if you wish to make the login non-persistent (like not checking "Remember Me" on login).