I set the authentication in control panel as below:
and i call the viewer by this code:
$.ajax({url: 'http://192.168.17.31/viewer',
headers: {'thisistheheadername':'thisistheheadername'},
type : 'GET'
});
but still request redirects to login page:
http://192.168.17.31/viewer/login
I'm not totally sure what you're trying to do. I've never seen AJAX used with Datazen like this, although I suppose I can understand how it might work. Of course, it won't be secure, because the browser could always indicate who the user should be--there's no checking.
The top chart in this answer might help you. But beyond that, what tells you it's sending to the login page? Where are you trying to display the results?
The two things I would check on outside of those, though, are:
Your header is not correct, unless you've got a user named "thisistheheadername" as well. You should be passing a username through that value. I don't recall specifically, but it could send you to the login page if it doesn't recognize the username.
Are you sure external authentication is enabled? I would check in the "Configuration" section on the server to ensure it isn't still "default." The core service must be stopped before changes are persisted.
Related
When the user clicked on the logout button after successful logout user redirects back to callbackurl with additional query parameters.
You can see below the URL return
https://localhost:9443/?sp={spname}&tenantDomain=carbon.super
Can anyone please help me with how we can remove these two sp and tenantDomain parameters?
I found the below article, also there are these two additional parameters.
https://piraveenaparalogarajah.medium.com/rp-initiated-logout-with-wso2-identity-server-b1fde28c4d80
Can search the below text in the article for reference.
Redirect to post_logout_redirect_uri
This seems to be introduced with the fix done for https://github.com/wso2/product-is/issues/3266. It has added the service provider name and tenant domain as query parameters for the success flow as well in addition to the failure flows.
Unfortunately, there is no way to configure this. But you may report this at https://github.com/wso2/product-is/issues and the team will decide whether this needs to be fixed.
This issue is reported for IS 5.10.0:https://github.com/wso2/product-is/issues/12723
How can I configure Polymer's platinum-sw-cache or platinum-sw-fetch to cache all URL paths except for /_api, which is the URL for Hoodie's API? I've configured a platinum-sw-fetch element to handle the /_api path, then platinum-sw-cache to handle the rest of the paths, as follows:
<platinum-sw-register auto-register
clients-claim
skip-waiting
on-service-worker-installed="displayInstalledToast">
<platinum-sw-import-script href="custom-fetch-handler.js"></platinum-sw-import-script>
<platinum-sw-fetch handler="HoodieAPIFetchHandler"
path="/_api(.*)"></platinum-sw-fetch>
<platinum-sw-cache default-cache-strategy="networkFirst"
precache-file="precache.json"/>
</platinum-sw-cache>
</platinum-sw-register>
custom-fetch-handler.js contains the following. Its intent is simply to return the results of the request the way the browser would if the service worker was not handling the request.
var HoodieAPIFetchHandler = function(request, values, options){
return fetch(request);
}
What doesn't seem to be working correctly is that after user 1 has signed in, then signed out, then user 2 signs in, then in Chrome Dev Tools' Network tab I can see that Hoodie regularly continues to make requests to BOTH users' API endpoints like the following:
http://localhost:3000/_api/?hoodieId=uw9rl3p
http://localhost:3000/_api/?hoodieId=noaothq
Instead, it should be making requests to only ONE of these API endpoints. In the Network tab, each of these URLs appears twice in a row, and in the "Size" column the first request says "(from ServiceWorker)," and the second request states the response size in bytes, in case that's relevant.
The other problem which seems related is that when I sign in as user 2 and submit a form, the app writes to user 1's database on the server side. This makes me think the problem is due to the app not being able to bypass the cache for the /_api route.
Should I not have used both platinum-sw-cache and platinum-sw-fetch within one platinum-sw-register element, since the docs state they are alternatives to each other?
In general, what you're doing should work, and it's a legitimate approach to take.
If there's an HTTP request made that matches a path defined in <platinum-sw-fetch>, then that custom handler will be used, and the default handler (in this case, the networkFirst implementation) won't run. The HTTP request can only be responded to once, so there's no chance of multiple handlers taking effect.
I ran some local samples and confirmed that my <platinum-sw-fetch> handler was properly intercepting requests. When debugging this locally, it's useful to either add in a console.log() within your custom handler and check for those logs via the chrome://serviceworker-internals Inspect interface, or to use the same interface to set some breakpoints within your handler.
What you're seeing in the Network tab of the controlled page is expected—the service worker's network interactions are logged there, whether they come from your custom HoodieAPIFetchHandler or the default networkFirst handler. The network interactions from the perspective of the controlled page are also logged—they don't always correspond one-to-one with the service worker's activity, so logging both does come in handy at times.
So I would recommend looking deeper into the reason why your application is making multiple requests. It's always tricky thinking about caching personalized resources, and there are several ways that you can get into trouble if you end up caching resources that are personalized for a different user. Take a look at the line of code that's firing off the second /_api/ request and see if it's coming from an cached resource that needs to be cleared when your users log out. <platinum-sw> uses the sw-toolbox library under the hood, and you can make use of its uncache() method directly within your custom handler scripts to perform cache maintenance.
I have a rssfeed application made in Adobe AIR. It uses the UrlLoader to read the feeds. I need the application to never prompt the user to enter password for a website or accept a certificate of a website if is no longer valid. I prefer to have it fail instead.
I have setup the event listeners for IO+Error and Security_ERROR but that is not enough
Sample urls(this may not work in future)
http://www.dawnanddrew.com/rss2.xml (asks for user and pass atm)
I had another issue with a feed that even if it was a http url the website redirected the loader to https and then the certificate validation failed and the user was asked to accept the certificate. I need this to fail (I mark failed feeds and the user can check them when they want to find the issue and fix them or remove them)
Using AIR (which you are), you can actually tell the application to NOT handle authentication.
var request:URLRequest =new URLRequest("http://www.dawnanddrew.com/rss2.xml");
request.authenticate = false; //default is true, so you need to tell your request to not handle authentication
Then it will fail with an IO error instead of prompting for credentials.
Documentation
Note however, this will only work in AIR and is not a supported property for flash player.
You cannot do it this way. Now, the server returns specific status and the browser reacts to it by showing you a login dialog box. You cannot do this directly in flash and you cannot get default login button. You need to implement this by your own. The perfect way to do so is to check (server side) if the user is logged in and if not - return status ok (200) with an error message (let's say JSON). This specific message would be read by the flash client and a login screen would be shown (custom made). You will also need to implement the login feature by yourself :)
Sorry for the bad news, but this is the way it is with flash.
I'm developing a flash registration form and I need to incorporate dynamic 'captcha' images for confirmation.
Can anyone recommend a best solution for doing this?
Captcha is used to prevent bots from submitting html forms which is easily accomplished since html is easily understood and processed programmatically. The same is not true for a Flash application. It would be difficult for a bot to generically submit Flash forms if it was not specifically made to target your site.
Therefore you don't need to worry about the spam problem captcha solves when working with a Flash application.
Making a strong captcha is not a trivial task. It must be hard enough for bots to fail, but easy enough for humans to succeed... I would take a look at existing systems and possibly use them. reCAPTCHA is popular http://recaptcha.net/ . It might be possible to use it through flash, but I have not looked into it.
It's not that different from a captcha in an HTML form, really.
Suppose you're using php on the server and you have a captcha.php scritp that generates the captcha image and saves its value in the session. In an HTML form, you'd use an element and set its src to captcha.php. The user would fill up a field with the text they see in the image. In the script that receives the post, you'd check if the user input matches the session value.
In a flash form, it's exactly the same. You load the image calling captcha.php and ask the user to type the extra field. Then, when you post the data to the server you pass the value typed by the user in the captcha field and the server matches that against the value it has stored in the session when you called captcha.php.
So, basically, it's the same as in an HTML form.
Chances are, bots aren't going to be written for your website. If the need ever arises, a simple "add these two numbers for me, k?" would be simple enough.
In all honesty, i doubt someone would write letter recognition to sign up a few hundred times on your website =/
You should be more worried about someone disassembling [or whatever the flash term is] your .swf s and simply sending "register" messages to your server =/
And yes, by that, i tried to imply that Captcha must be applied server side, or, really, its not that hard to go around.
We had a strong need to implement CAPTCHA into a flash animation/form.
The most important point to note is that either FF or IE (can’t remember which one) doesn’t send any cookies back with a web service call. So if you’re submitting your form to a .Net web service you can’t use the session state of the http request to store the captcha text and then compare the user entered captcha value on submttion to the web service (session enabled web method)
We implemented the following:
Set a unique token value (Guid) on the web page
pass this token as a flashvar to the flash movie
load the captcha image into the flash with the token as a url param. Ie captchaImg.aspx?t=xxxxxxx
during that request save the random captcha text in a table with the token
when the user submits their form, compare the token and user entered captcha value with the one in the table
This approach works very well for us.
It’s also web farm safe.
public class Captcha extends Sprite{
private var question:String = "How do you feel?";
private var _answer:String;
private var isRobot:Boolean;
public function Captcha(answer:String){
_answer = answer;
}
public function checkAnswer():Boolean
if(answer != "sad"){
isRobot = true;
return isRobot;
}else{
isRobot = false;
return isRobot;
}
}
}
Say a user is browsing a website, and then performs some action which changes the database (let's say they add a comment). When the request to actually add the comment comes in, however, we find we need to force them to login before they can continue.
Assume the login page asks for a username and password, and redirects the user back to the URL they were going to when the login was required. That redirect works find for a URL with only GET parameters, but if the request originally contained some HTTP POST data, that is now lost.
Can anyone recommend a way to handle this scenario when HTTP POST data is involved?
Obviously, if necessary, the login page could dynamically generate a form with all the POST parameters to pass them along (though that seems messy), but even then, I don't know of any way for the login page to redirect the user on to their intended page while keeping the POST data in the request.
Edit : One extra constraint I should have made clear - Imagine we don't know if a login will be required until the user submits their comment. For example, their cookie might have expired between when they loaded the form and actually submitted the comment.
This is one good place where Ajax techniques might be helpful. When the user clicks the submit button, show the login dialog on client side and validate with the server before you actually submit the page.
Another way I can think of is showing or hiding the login controls in a DIV tag dynamically in the main page itself.
You might want to investigate why Django removed this feature before implementing it yourself. It doesn't seem like a Django specific problem, but rather yet another cross site forgery attack.
2 choices:
Write out the messy form from the login page, and JavaScript form.submit() it to the page.
Have the login page itself POST to the requesting page (with the previous values), and have that page's controller perform the login verification. Roll this into whatever logic you already have for detecting the not logged in user (frameworks vary on how they do this). In pseudo-MVC:
CommentController {
void AddComment() {
if (!Request.User.IsAuthenticated && !AuthenticateUser()) {
return;
}
// add comment to database
}
bool AuthenticateUser() {
if (Request.Form["username"] == "") {
// show login page
foreach (Key key in Request.Form) {
// copy form values
ViewData.Form.Add("hidden", key, Request.Form[key]);
}
ViewData.Form.Action = Request.Url;
ShowLoginView();
return false;
} else {
// validate login
return TryLogin(Request.Form["username"], Request.Form["password"]);
}
}
}
Just store all the necessary data from the POST in the session until after the login process is completed. Or have some sort of temp table in the db to store in and then retrieve it. Obviously this is pseudo-code but:
if ( !loggedIn ) {
StorePostInSession();
ShowLoginForm();
}
if ( postIsStored ) {
RetrievePostFromSession();
}
Or something along those lines.
Collect the data on the page they submitted it, and store it in your backend (database?) while they go off through the login sequence, hide a transaction id or similar on the page with the login form. When they're done, return them to the page they asked for by looking it up using the transaction id on the backend, and dump all the data they posted into the form for previewing again, or just run whatever code that page would run.
Note that many systems, eg blogs, get around this by having login fields in the same form as the one for posting comments, if the user needs to be logged in to comment and isn't yet.
I know it says language-agnostic, but why not take advantage of the conventions provided by the server-side language you are using? If it were Java, the data could persist by setting a Request attribute. You would use a controller to process the form, detect the login, and then forward through. If the attributes are set, then just prepopulate the form with that data?
Edit: You could also use a Session as pointed out, but I'm pretty sure if you use a forward in Java back to the login page, that the Request attribute will persist.