Using the browser client, how can I set the sounds.disconnect() on every call? Is there a way to access the device singleton to modify that setting? I know I can access when I get the device.ready callback, but I want to modify the setting on every call.
I received a helpful reply back from Twilio support:
--
That parameter will be instantiated in Twilio.Device either True or False once the web page loads, so to change it, I believe you would necessarily need to also reload the page.
This would create another control layer in effect, that isn't provided out of the box by Twilio: you'd need to build a web page to change the variable that determines sounds.outgoing(), and then trigger the page to reload.
Another option would be simply create a second Client instance running on a separate tab, and have both instances use the same outbound caller ID. That might be easier.
--
In my scenario I'll need to find a different approach, and will look in to disabling the Twilio sounds and using my own.
Related
I'm building a website for a client (real estate), and on the website are links to a different website (adverts for properties). My client routinely activates and deactivates these adverts when he rents out a certain property.
The hrefs on my links look something like this:
<a href="https://domain.xx/estate/idxx/des-crip-tion-xx-xx-x-xx/">. If the advert is indeed active, it just takes them to the advert. If it is not active, however, the website in question redirects the user to https://domain.xx/estate-for-rent/city/, effectively sending the users to my client's competition.
I wish to implement some logic where, before handing the users over to the other website, the server checks to see if it is redirected to https://domain.xx/estate-for-rent/city/, or some similar logic, and if so, uses preventDefault, or something, and notifies the user that the advert is not available instead of sending them to the other website.
I wonder if I can use the fact that only if the advert is active does the resulting url in the users browser window (after they've been directed to the other website) match the url in my href. Can i somehow get the server to try to access the url in my href, and have it see where it gets redirected, and then do something based on that? On the back-end, I'm running NodeJS with Express by the way, and if it matters, I'm relying heavily on EJS for templating. Thanks in advance for any help!
This sounds more like a problem you could solve on the client as opposed to the server. For example, at a high level here's how I would do it:
Handle the click event for each link (really simple to do a catch-all with jQuery)
Fire off a HEAD request via AJAX to the destination URL (this would be much more efficient than a GET but depends on the external service supporting this verb)
Use the status code to determine what to do next (e.g. 2xx allow redirect, 3xx pop a message and block)
Does IBM Domino track the last login date for web users(UserName/Password and internet certificate)? I know the access logs contains this information but wanted to know if there may be something built into Domino (maybe in Address Book). Trying to come up with a method to disable web accounts that have not accessed a domino server in a specified time period.
Thanks,
Kev
The User Activity area in the Database Properties picks up from the log.nsf, which is where this information is stored. But, typically, the log.nsf will only have a few days' worth of information. When I've had this requirement before, I've manually captured it via a custom login page or an initUser function I've had in applications.
One of the easiest solutions is to trigger an action from a live web page that generates a database.nsf?openagent event.
like:
or
Ideally you've use the openagent to print a content type and a response, but if you don't browsers do pretty well with invalid responses from servers.
inside your "myagent" you will have the users name available to you to write it to a document.
Your next challenge will be in getting the agent to trigger, but, not too often, ideally only on login.
When a user uses a custom login form it submits the username/password and redirection url in POST method. You could change that to ...?openagent&nexturl=/blablabla.nsf
Your tiny little agent would run one and only one time upon login and update a document in a your custom logging database.
That's a developer's solution.
There are also admin solutions. The server does keep track of active web sessions, but, it does not drop them into the log.nsf like it does upon session ending for a notes session. I don't think it would be too much work from an admin standpoint to get that information there are a lot of event triggers available to you. It's just been way too long since I worked on any server that anyone cared about statistics.
I need to secure the install web hook so I would know that the request is coming from Branch.io and not from something else.
The are saying it can be done like this
But, where I can set that custom event (key, value) on the mobile side of the application?
I ended up putting a parameter in the branch link and when the event reaches the server I check for the parameter value.
It's over https so I guess it's secure.
Alex with Branch here: as you discovered, unfortunately it's not currently possible to add a (key, value) pair to Branch's default install event. Your method of appending a parameter to the incoming Branch link is a good solution, as long as you only need to catch users who have opened that Branch link prior to installing the app.
For an approach that covers all installs, including those not coming through a Branch link, you could use a custom event configured to fire on the same criteria as the install event:
Initialize a Branch session in your app.
In the callback parameters (full list here), check for the value of +is_first_session.
If +is_first_session returns true, then this is the first time that device has been seen (a.k.a., the criteria for install) and you can define a custom event with the secret (key, value) pair of your choice.
For example, using Objective-C for iOS:
[[Branch getInstance] userCompletedAction:#"myCustomEvent" withState:#{#"branch_specific_identifier":#"123-AB-456"}];
Then when you configure your webhook on the Branch dashboard, you can take a couple of different approaches:
Pass all myCustomEvent events to your endpoint, and then examine the postback to ensure branch_specific_identifier is set appropriately (this is similar to what you're probably already doing with the link parameter).
Use webhook filters to prevent myCustomEvent events without appropriate branch_specific_identifier values from being sent to your server at all. To do this, you would use a (key, value) pair of event.metadata.branch_specific_identifier : 123-AB-456 in the Filter (Advanced) box of the webhook configuration screen.
Hope that helps!
I couldn't make a request to a remote server using JavaScript in the onload function due to access is denied insanity. So, just to make CRM obey, I set up an IFRAME and connect that to a HTML page running my JavaScript. Now, provided that I get some values inside the script (run in an IFRAME) how can I communicate them to a method in the holding parent?
Not quite sure how to explain it more detailed so please feel free to ask.
The access is denied is the Same Origin Policy. You're going to run into the same problem from the IFRAME unless you're serving the page or just the script src from the same server you're subsequently trying to make the AJAX request to.
Assuming you are doing the latter then you just need to make sure you have unchecked the "Restrict cross-frame scripting" option on the IFRAME you added to the CRM form. From the IFRAME you will now have access to your function that you've defined at global scope on the parent CRM form via window.parent.yourfunctionNameHere(xyz).
postMessage sounds like it might fit.
window.postMessage, when called, causes a MessageEvent to be dispatched at the target window when any pending script that must be executed completes (e.g. remaining event handlers if window.postMessage is called from an event handler, previously-set pending timeouts, etc.). The MessageEvent has the type message, a data property which is set to the string value of the first argument provided to window.postMessage, an origin property corresponding to the origin of the main document in the window calling window.postMessage at the time window.postMessage was called, and a source property which is the window from which window.postMessage is called.
To use window.postMessage, an event listener must be attached:
// Internet Explorer
window.attachEvent('onmessage',receiveMessage);
// Opera/Mozilla/Webkit
window.addEventListener("message", receiveMessage, false);
And a receiveMessage function must be declared:
function receiveMessage(event) {
// do something with event.data;
}
The off-site iframe must also send events properly via postMessage:
<script>window.parent.postMessage('foo','*')</script>
Any window may access this method on any other window, at any time, regardless of the location of the document in the window, to send it a message. Consequently, any event listener used to receive messages must first check the identity of the sender of the message, using the origin and possibly source properties. This cannot be understated: Failure to check the origin and possibly source properties enables cross-site scripting attacks.
Source: https://developer.mozilla.org/en/DOM/window.postMessage
Recently I had the joy of connecting to a web service and retrieve some data. When that’s been achieved, I found myself sitting on the said data not exactly knowing where to put it.
To make the long story short, I used the following source code.
parent.window.Xrm.Page.data.entity.attributes
.get("new_Konrad").setValue("Viltersten");
Notable is the fact that in order to communicate with the parent form, the HTML file (where my JavaScript resided), needed to be placed as a web resource within the CRM structure. By other words, just by pointing to an external “http://some.where/some.thing” we can consume a service but won’t be able to convey the obtained information up the CRM server, at least not when developing a solution for the on-line version.
It is a well known problem to every web developer. As far as I tried to find a good solution to this problem - there was none (or at least I could not find it).
Lets assume the following:
The user does not behave, as he was expected to. The actual project I'm working in uses a navigation within the web portal. But if the user uses the browser's back button, the whole thing becomes jeoprady[?] and the result was not always predictable.
We used the struts framework and stored the back-url into forms - at some places, where we needed a back-url - this has been rendered out of this form's back-url. For there was only a singe field for this information and therefore it was not possible of going back multiple steps.
When you change the "struts-flow" - which may result in using a different form - this information will be lost.
If the user dares to put a bookmark somewhere within your webapp - this information may never have been set and again the result will again be either unpredictable or not flexible enough!
My "solution":
I was storing every navigation-relevant page the user visited onto a stack-like storage into the session. This means a navigation-path is collected and stored for later navigations.
At any page within the webapp, where back-navigations are involved I used a self-made tag which renders the stack-content into the url.
And thats it.
When this back-url was clicked, the stack has been filled with the content from the back-url clicked by the user (which holds all information from the stack once the back-link was rendered).
This is quite clear, because a click on a link is a clear state, where the web developer exactly knows, where the user "is" a this very moment - absolutely independant from whatever the user did before (e.g. hitting the browser back button multiple times). Then the navigation stack is built upon this new state.
Resumé:
It becomes clear, that this won't be the best solution. But it allows storing additional information on the stack like page parameters and some other useful stuff (further developments possible).
So, what were your solutions to this problem?
cheers,
mana
The stack solution sounds interesting, but it will probably break if the user chooses to navigate "in parallel" on different tabs or using bookmarks.
I'm afraid I don't really understand why you have to keep all this state for each user: ideally the web should follow the REST principle and be completely stateless. Therefore a single URL should identify a single resource, without having to keep the navigation history of each user.
If your web app relies heavily on AJAX, you could try to implement something like GMail (admittedly, not so easy...), where each change in the interface is reflected in a change in the page URL. Therefore each page is identified by the current URL and the user can navigate concurrently or use the back button as usual.