I have created a number of devices in my Xively account and always selected "private access" in the create wizard. I recently noticed that some of these devices are publicly accessible, even though the Xively portal is telling me they are private. If I use the portal to change the access to public and back to private again then they are no longer publicly accessible. Does anyone know why some devices are public when the portal says they are private?
I've found the reason for this now. There are actually two problems which combine to cause what I think is quite a nasty data privacy issue.
Firstly, the Xively portal does not accurately reflect the current accessibility status (public or private) of a feed; it shows the status that was selected when the device was created or subsequently modified via the portal, however if an application changes the status via the API this change is never reflected in the portal UI. If your application accidentally changes the status from private to public the portal will continue to display "private" whenever you look at it.
Secondly, there is a bug in the Xively Java library which changes a device's status to public whenever you use the library to update a device (e.g. submit a reading). The update() method of the FeedRequester class submits every attribute for a feed whether you specify the attribute or not. In most cases this doesn't matter because the method sends a value of null for unspecified attributes which the server (presumably) ignores. The one exception is the "private" attribute - in this case if your application does not specify a value the library will send a value of false, not null, presumably because the attribute is stored in the Java library as a Java primitive type (boolean) and not an object. The net effect is if you call this method without explicitly setting private to true, your device's status will be changed from private to public without you realising it.
Related
I want to override my web API's component name shown in the Application Insights transaction search.
I am already setting the cloud role name, which has previously worked well, and even now works for some of the telemetry, as indicated by the single green marking on the image. However, almost all telemetry seems to ignore the cloud role name and instead uses the URL host as the component name, indicated by the three red marks on the image. Is it possible to override this?
I can confirm that all the raw JSON telemetry data sent to AI has ai.cloud.role set to the correct value. Furthermore, I find no traces of the host in the raw telemetry data that is sent, other than in the URL of course. This makes me believe that the component name is set directly by Azure Portal and is not possible to override. This assumption is supported by the fact that the single telemetry item on the image with the correct component name represents a call to my component from Azure Service Bus, i.e. not a HTTP call.
I want to know what is exactly the behaviour of wlCommonInit() function.
I have moved my initialization code into this function, but then it seems to be not called in the case of connection to the server failure.
is wlCommonInit() called when the Worklight server is not reachable ?
If I want to use direct update, I want to call WL.Client.updateUserInfo() on my initialization, and I want the app to be working also in offline mode, does this mean I must implement onConnectionFailure in wlInitOptions ?
If I implement onConnectionFailure in wlInitOptions, can I display the default popup that inform about the connection failure, and provide details ?
It really depends on the logic you wrote in your "initialization code" IMO. The question is somewhat cryptic...
The wlCommonInit function is called once the Worklight framework has completed initialization. If you set connectOnStartup to true, only if connection to the server is successful, it will then be called.
Direct Update is not related to any specific API you implement in your application. If you change any web resource in your project (HTML, CSS, JavaScript, images, ...), this will trigger a Direct Update in the application.
A Direct Update is checked in 2 scenarios:
on application launch, and
on return to the foreground (if the app was in the background)
The Direct Update check is performed only if and when the application connects to the Worklight Server. If you did not previously set your application by either using connectOnStartup:true or used WL.Client.connect or invoked an adapter procedure (all three send a request to the server), the Direct Update check will not be done.
If you choose to override the default dialog provided by Worklight by using onConnectionFailure, the Details button (which I assume if what you wanted) - is not available. By overriding, you select to fully customize it.
I'm creating a generic flexible site that I can use over and over again but with different features activated or deactivated. I'm looking for the best method to approach my solution.
Specific areas will need to be closed off in certain circumstances, for instance, the application will contain an event management page, but it will not always be required. The application will pull out the active and deactivated features from a data source.
They're going to be like Application wide settings, that will be required on each page, hiding away those settings that are turned off from the menu and not allowing users to access the deactivated feature pages.
I have thought of a number of ways to achieve this :
Store the feature statuses in the database, then on each time the page / menu is accessed / displayed, call the database requesting whether to hide the page / menu item.
Store the feature statuses in the database and access them on the application startup, store them application wide then they can be accessed as and when.
Put the feature statuses in the web config, this way we don't need to query the database every single time or have globally accessible properties.
I would like you advice on which method would be best, or if a better method is available I would be grateful. I don't want to hit the database too many times, or would a simple check like this not be too performance expensive? I'm also not sure if the web config is secure enough for managing active site features.
Regards,
I think putting configuration in configuration file(web.config) would be better option. Because while displaying page/loading menu going to database every time to see whether it should be de/active, required database trip which is overhead.
And if the configuration is stored in web.config it is easily accessible by admin and also easy to modify without compiling or changing anything.
So, in my view best option is to store configuration in web.config. In addition to that you can also make administration page which will change configuration settings and should be reflected in configuration file.
I suggest 2nd approach - store the settings in the database and then retrieve them at startup and store in application scoped containers.
The advantage of such approach over the web.config is that you can easily take client database and immediately run it in your development environment for testing/debugging. If, on the other hand, some settings are stored outside of the database, cloning the site means that you not only have to clone the database but also all the settings from various other resources (like the web.config).
The answer depends on how often you will be changing the status of the features.
If you are going to only set the statuses once when you clone the site and will never touch it again, go with option #2 (load on application start).
If there is any possibility that you will need to change the status of the features in the future, go with option #1 (get statuses on each page load). A simple datareader read to the db will not affect the speed of your site. The db is your friend, remember that's what it is there for. Also, if you ever need to change the statuses while the site is up and running, this method allows you to do so without restarting the entire application.
Whatever method you finally decide to implement, make sure the "application wide" location you store the settings is multi-threaded ready. Remember, each page request will be run on a separate thread and they will all access the same resource.
My suggestion taken from MS (multi-thread safe Singleton Pattern):
using System;
public sealed class Singleton
{
private static volatile Singleton instance;
private static object syncRoot = new Object();
private Singleton() {}
public static Singleton Instance
{
get
{
if (instance == null)
{
lock (syncRoot)
{
if (instance == null)
instance = new Singleton();
}
}
return instance;
}
}
}
I have clientside user-settings manager. the settings are saved through a webservice. I´m serializing them into json. Since the json can be manipulated before sending, I want to validate it on server then.
What are the best practices, what have i to look for?
Validating before deserialization? What kind of malicious input can the user use? Can he manipulate the json so that it harms me somehow on deserialization using default asp net javascript deserialization?
var userinput = { param1 : "test", categories : ["2312", "4324", "2122"] }
this one is sent to the server, serialized.
Deserialized on server into an object graph.
public class usersettings
public property param1 as string
public property categories as string()
end class
param1 is regex checked, maybe only letters and digits, start with letter, maximum 10 signs, for example.
categories must be distinct, not more than 10...
the usersettingsclass is a linq to sql genereted object, that can be directly pushed to the sqlserver.
this is all a very simple sample. in the userinput can be anything.
Are these settings security sensitive? What happens if the user messes with them?
If the only thing that happens is you can an exception, then don't bother.
If these settings can somehow compromise security, then they shouldn't be client side unless they're encrypted by the server before they're sent down to the client. In other words, they're "on the client" for scalability reasons only, not because they're manipulated in any way by the client.
If these settings are security sensitive, and they must be modifiable by the client, they you have an untenable situation. If javascript can modify them, so can the user.
Lastly, if all your'e worried about is that the client somehow manipulates the json data so that it causes a deserialization exception, you should research if there are any vulnerabilities in your json library. If not, don't worry about it until they're are.
Since you mentioned you're using built-in ASP.NET libraries, I can say that I'm unaware of any known vulernability in these libs.
I have an "enevelope" schema and a body schema and I have setup the correct properties on the "envelope" to point to the body.
I also have a property schema for promoting a value in the body message so that i can route on it.
I set up a File drop receive location and two send ports. Each send port subscribing on a different value of the promoted property. The receive location uses XmlReceive and the send ports both use XmlTransmit.
When i drop one envelope message at the Rcv location, Bts picks it up, splits it, promotes the property and my send ports pick up the relevant messages and do their thing.
File drop was fine for testing, but the real scenario is slightly different.
I want clients to submit "envelope" schemas containing multiple document elements via Wcf
So i published the envelope schema as a Wcf endpoint using the publishing wizard. Let it create the new Receive location. Wired up a Wcf client to talk to this endpoint and submitted a message.
Without changing anything on the Send ports in BizTalk I expected the same result;
However I now get a routing failure.
If i remove the extra filter in the Send port that filters on the promoted property it works, no routing failure.
So ... it would appear that the promoting of my property is not happening on the Wcf receive location.
I have checked; the Wcf receive location is using XmlReceive.
What gives?
How do i fix this?
I would guess that the namespace of your incoming message has changed as a result of changing it to use WCF.
This can cause the property promotion to no longer match the incoming message.
You can view the property promotions in the tracked messages in the BizTalk server admin tools.