Keep in mind, I'm not looking to "turn on" autofill on my browser, but rather, I'm working on behalf a web property that wants to implement this feature so their customers can have form data autofilled.
It seems that I can only find browser specific info for how to turn it on, but not how to set it up. I have browser autofill turned on right now, and it works for other sites, but not ours. So, how do I get it to work on our site?
Related
I'm currently working on a browser extension project for an affiliate marketing business. Affiliate marketing usually works by setting tracking cookies on click to identify the referrer in case an article is bought on the partner's website and rewards the referrer afterwards.
How can some browser extensions "activate cashback" or "activate affiliation" without having the user to go through a redirect page? How can they apply all the tracking cookies with no apparent redirection?
Options I considered:
Creating an API endpoint that would store an array of cookies set during the chain of redirection then applying them directly on the browser. Problem: some platforms use client script with URL matching to set cookies on landing on the partner's website.
Maybe it has something to do with form posting hack: https://stackoverflow.com/a/4702110/7576507
Furthermore, how can one know that the tracking cookies have been well set?
It seems that these browser extensions create a tab using a standard affiliate link without focusing it.
Once it is completely loaded (DOM, external scripts etc...), they close it and display on the main tab that tracking has been activated.
At my company we have an internet-facing SharePoint 2010 site. We will be creating a subsite that will serve as a mobile site (different design, smaller subset of information). When a user hits our homepage from a mobile device, I would like them to be redirected to a page where they can select a link to either view the mobile site, or the full desktop site.
Correct me if I'm wrong, but I believe standard SharePoint mobile detection needs to be enabled for this. I think I can redirect the mobile users to my "choice" page pretty easily with an HttpModule, so that they don't hit the default SP mobile page. But the problem I'm having is that if they choose to go to the full desktop site, if I try to redirect them there in the module, they're just going back to the default SP mobile page.
My question is, is it possible to achieve this in SharePoint? It seems to me that the default mobile detection would be difficult to override the way I want it to happen. Do mobile users only have access to the mobile subsite in this scenario? If anyone needs more information from me, just let me know, I'll provide whatever I can.
(Also, I know it would be better to do a responsive layout, but that decision is out of my hands)
We created an "ismobile" cookie for the session after the redirect. This allows us to ignore the redirect if the user has this cookie. In means that they have already been redirected once this session so don't do it again if they hit the desktop page.
We started using this so that the "Show full website" link didn't just bounce the user back to the mobile page
I've messed around with FBML (deprecated, I know) and the newer HTML5 code to no end, but so far I haven't found any way to do what I'm looking to do.
When using "apprequest" within an application on Facebook (within iframe), I can allow users to share requests to join the app, but those messages that get sent are very hidden away. They don't seem to appear in the newsfeed for shared recipients, and we're afraid users won't see the request from their friends.
Instead, we thought we'd allow users to alternatively share to their friends with the "send" button code that Facebook offers up. This allows us to specify a URL (we were thinking the app canvas URL or page tab it would live on).
So far, this is all I could generate...
Is there any way to have the send code let me specify that we want faces with checkboxes for uses to select their friends, instead of a sharing party needing to type out names of their friends by hand? There's got to be some easy way of doing this.
Stop me if you think I'm going in the wrong direction on this. Maybe there's a better way that I'm simply not thinking of.
Here's an example of the checkbox functionality I'm referring to...
This violates the browser security model and also Facebook's policies, you can include a to parameter with the send dialog to preselect one recipient, but you can't modify the browser DOM because the Facebook dialog is in an iframe
Background:
I am working on a legacy ASP.NET 3.5 Web Forms applications. The application allows users to buy a subscription to a 'white-label' website which is generated for them and they can customize it further. It uses forms authentication.
A typical use-case is that the user creates an account on our system, purchases a website, and then proceeds to customize their website. The URL they will use to edit their purchased website is something like this: https://www.example.com/EditWebsite.aspx. There are many other pages also within our website editing toolbox with other URLs.
Problem:
My team has now been tasked with allowing people to use one account to access multiple website subscriptions. This means that one authenticated user could be trying to access one of many websites to edit if they use the URL mentioned above. Our system can be made aware of multiple subscriptionIds per User but the website editor web app only has support for one subscription.
To clarify with a simpler example: this would be like if Google all of a sudden allowed you to view two different inboxes with one GMail account. How would the system know which one you were trying to access if the URLs were the same for both?
We originally wanted to change the application to use URLs like: https://www.example.com/[subID]/EditWebsite.aspx which would give us all the information we need to send the user to the correct website. We looked into URL Routing to accomplish this but it seems that we would have to change all of the web app's internal links to use the route config to generate the correct URLs. Maybe we have the wrong idea here but it seems like too much work for a legacy application.
Another potential solution we came up with was simply using our systems' control panel web app (where they click links to edit any of their websites) to set a session cookie which our edit website web app can read to know which website to bring up. This has the disadvantage that the pages would not be bookmark-able and you could not look at multiple websites at once in different tabs of the same browser.
Question(s):
Is there any other options we have not investigated or thought of? Is there any other web sites which allow for this kind of behavior; how do they handle it? Is URL Routing the right way to do this and we just need to take the plunge?
Any input is appreciated!
The solution we ended up using was adding a URL parameter to the link which specifies which website you are trying to edit.
https://www.example.com/EditWebsite.aspx?subID=123
This parameter is included in the links to 'Edit Website' from the page which lists all of a user's websites.
When present, this sets a session cookie for the user. If the request parameter is not present, the app looks for the cookie being set; this handles all the internal links within the application. if a cookie doesn't exist and the request parameter was not set, we just pick the authenticated user's first subscription from the list.
This isn't perfect but it has worked without issue so far. The only consequence it has caused is that a user cannot edit multiple websites in the same browser session, e.g. using multiple tabs. This hasn't resulted in any support issues yet though so it is pretty much a non-issue.
I know about test accounts, but during beta I'd like to allow access only to my friends, and then later friends-of-friends, and then only eventually Kevin Bacon and his friends.
That would probably suck, wouldn't it? The app would be listed (is there a way to prevent listing?) and someone I don't know might try it and get a "sorry, this is in development message." I imagine they'd be irritated and not come back.
From what I've read, only a few apps take off, but when they take off, they REALLY take off. Do developers just release these things fully baked?
Anyone start out with OpenSocial or other smaller-than-Facebook networks?
Any ideas for a soft, gradual, restricted roll-out?
Once you've set up your application, there is a setting in the Developer application control panel for your app: Your app -> Advanced -> Sandbox Mode.
Sandbox mode lets you restrict access to only those people listed as developers (under the Basic section).
In terms of expanding the app, Facebook doesn't provide much more flexibility that the Sandbox mode. Unfortunately, adding everyone as Developers of the app doesn't work very well for a beta, as people can access the application control panel once they are a developer. I ended up putting a whitelist of Facebook Ids into the front controller of my application for a previous beta, and it worked fairly well.
The apps are only listed in the App Directory if you submit them and they are accepted. There's no issue about preventing listing, it's something you have to apply for.
As for restricting users, you can accomplish it with a script in the application that checks whether the currently logged-in user is within your restricted user set. For example, if you only want friends of yourself, check whether the current user is friends with your user id. If not, simply display an error/message page or redirect them to the Facebook home page (or wherever). Add this check to the rest of the start-up logic run each page (such as connecting to your DB and authenticating with Facebook).
What I have done in some cases is keep a database table with the user id's of users who are allowed access, essentially a "whitelist". If the user isn't in the table, redirect them.