Can chatter posts be accessed in sites pages? Both, reading chatter posts and adding comments from a sites page that is using the guest site user login account?
If you make an Apex controller that is without sharing, then yes, you can expose Chatter posts on a Sites page (although you might have to recreate the user experience, I'm not sure if the default Visualforce components would work that way).
Adding comments is another matter though -- I doubt you'd succeed in getting the guest user to add a comment (although this is pure conjecture -- I haven't actually tried it myself so who knows, it might work). In this case you'd probably have to write the controller such that it added any comments as some existing regular user in the system.
Also, it's worth noting the existence of Chatter Answers, which is a way to expose a limited chatter feed on Sites. If this maps to what you're trying to do then it might save you some time.
Related
I'd like to create visualforce page that inserts a record into salesforce account object. However, I expect some of the page users won't have salesforce accounts. Can they still access it? If not, what are the alternatives that can be used to visualforce page in this case? (Please don't consider Web to Lead Forms).
Thanks,
Yes, it's possible. Go read about Salesforce Sites. For a start:
http://wiki.developerforce.com/page/Websites
http://wiki.developerforce.com/page/An_Introduction_to_Force.com_Sites
(of course it's also possible to write that page in say Java/.NET/PHP and use integration via SOAP or REST to talk to Salesforce... but these 2 main links will keep the whole solution within SF so no need to need to learn new language, have extra maintenance effort etc)
Sites are VF pages that expose a bit of your company's data without need to log in. You can use them to input data too, just remember that in theory anybody could learn the link and spam you (not too different from web2lead, inbound email handlers etc). You specify security in a way similar to Profiles, the records will have "Created By = {site name} Guest User".
I don't think there's anything out of the box to restrict visibility, they're open to whole world. So if you would want something similar to login IP ranges (so only sales reps from your office's network can enter data) - you might have to write some logic in the controller.
I am exposing a page with a standardcontroller="account" to a force.com site facing the public. This page displays account specific data to the clients. Now when a customer logs in to my website I want him to have access to his account's data and only his account data. Here is the problem; the url for a page with a standardcontroller has a Id field, such as "https//www.myforcesite.force.com/AccountViewPage?Id=a82347dod". If a user changes a few keys on the Id, it is very easy for him to access other people's account page and bypass the login process. How can I prevent that.
I opened a ticket with salesforce but they told me its working as intended. I don't think a vulnerability to a trivial brute force attack should be intended so I want to know if there are any fixes?
Create one StandardController extension and check if the logged user in your website has the permission to view that account.
http://www.salesforce.com/us/developer/docs/pages/Content/apex_pages_standardcontroller.htm
What you are looking for is URL rewriting for force.com site.
For example, let's say that you have a blog site. Without URL rewriting, a blog entry's URL might look like this: http://myblog.force.com/posts?id=003D000000Q0PcN
With URL rewriting, your users can access blog posts by date and
title, say, instead of by record ID. The URL for one of your New
Year's Eve posts might be:
http://myblog.force.com/posts/2009/12/31/auld-lang-syne
I have been struggling all day with an issue. I am sure there must be some easy solution that lots have already implemented as it looks to me as a basic setup.
I am building an app with GWT and appengine using requestfactory. This app has some "pages" (they are actually MVP views) that everybody should have access to. It's like the home page and a couple of views where the service we provide is described. Then if you want to use the service you have to login (with google accounts and all that). Only being logged in you have access to the rest of the views (pages) in the app. The question is, how to handle this?, the fact that some pages and some requestfactory calls are public and some other have to be available to those that have logged in?
I have already discarded the auth-constraints tags in web.xml because they work with all or nothing.
The next alternative was to use servlet filters (as the expenses demo does). That could work, but only if the "open" or not secured pages didn't need to access any data from appengine datastore (and I don't want to close that door, maybe in the future I want to show status or number of users, etc etc). The reason for this is that with request factory you only have one servlet so if you put a filter you shut down all comunication with appengine if the user is not logged in.
I was thinking of implementing this filter, with requesfactory for all the stuff once the user is logged in and also implement some RPC services for the data i might want to display in the "home or information pages" that i might need to retrieve from the datastore. However it looks a bit overkill for me.
Another alternative is to implement a check that the user is logged in all the request factory service methods that i want to protect. But that doesn't look to elegant either...
Anyone had the same problem? any ideas?
I'd appreciate any help on this.
Thanks,
You say that the auth constraints are "all or nothing", but that's not true - they're per-url. See here for details. Also, your connection of servlet filters and datastore access is a non-sequitir - the two have nothing to do with each other.
I'm looking at ways to secure the admin section of my (cakephp powered) Facebook application. To avoid duplicating functionality, I thought it'd be neat to allow access to people who have been flagged as developers in the app settings.
The question could then be: How do I determine whether a user of my Facebook application is a developer?
Alternatively: How do I obtain an array of developer user IDs for my Facebook app?
I tried looking for your answer myself, and the only thing I found that you could possibly do is to make a group private and invite-only to developers and then use the fb:if-is-group-member tag. http://wiki.developers.facebook.com/index.php/Fb:if-is-group-member
OK, so I found out how to do it by myself. Props to Samuel for giving me the idea.
Basically, the way to do it is to run an FQL query that establishes whether a user is an admin of the applications page (page_admin).
SELECT uid FROM page_admin WHERE uid = 286302657 AND page_id = 31290624157
In the PHP client, this returns an array for developers and an empty string for anyone else.
I decided to use the FQL rather than the API call because it is possible to preload the FQL to reduce calls to the Facebook servers.
Hope this is useful to somebody.
I want to write a program that analyzes your fantasy baseball team and notifies you of recommended actions, possibly multiple times per day. The problem is, you aren't playing fantasy baseball on my site, you're playing on yahoo, or cbs, or espn, etc.
On the majority of these sites, fantasy teams and leagues are not public, so you must be logged in and a member of the league to see the teams in the league.
All that I need is the plain html for the team page on each of those sites to be sent to my server, where I can then parse and analyze the file and send user notifications.
The problem is that I need username/password combinations to easily get this data to my server when I need it, and I think there will be a lot of people who wouldn't want to entrust their yahoo/espn/cbs password to me.
I have come up with several possible ways to solve this problem:
The most obvious way is to ask for their credentials for the site on which their team is hosted. Then I could just programmatically log in and request the data I need. I'm guessing a number of people would be comfortable giving me their credentials, and a number of them not so much.
Write a desktop client, which the user then downloads. The client would require their credentials, but it could then basically do exactly the same thing that the server based version would do, log in, request the page, and send the page back to my server. The difference being that their password would never need to leave their desktop. Their computer would need to be on, and this program running for this method to work.
Write browser add-ons that navigate to the page I need, use the cookie that is saved from a previous login to login to the site, and send the page back to my server. This doesn't require my software to ever ask for their password, but if the cookie expires I am hosed, and I don't know much about browser add-ons besides.
I'm sure there are other options, but these are what I've come up with so far.
I have two questions:
1. What are the other possibilities for this type of task?
2. Am I over-estimating people's reluctance to give me their yahoo (for example) password? Is option (1) above the obvious choice?
It was suggested in the comments that I try yahoo pipes, and that looked like a promising suggestion so I explored it a bit. Having looked now at this, I don't think that is an option. So, it looks like I'll be going with option 1.
This is a problem I grappled with a couple of years ago when I wanted to do the same thing. Our site is http://benchcoach.com and the options we were considering were the following:
Original we considered getting the user's credentials and login. We would then log in and scrape their league and team info. The problem there is that after reading several of the various terms of service, this would definitely be violating the terms of service. On top of this, Yahoo! was definitely one of the sites we were considering and their users have email (where we could get access to sensitive data), and Yahoo! wallet. In addition, it would be pretty trivial for Yahoo/ESPN/CBS to block our programmatic logins by IP Address.
The solution we settled on (not 100% happy but it does seem to work) was asking our users to install a bookmarklet (like delicious, digg or reddit) which would post the current html page to our servers, where we could parse the data and load our database. If they were still logged into their Yahoo/ESPN/CBS account, we would direct them directly to the pages, otherwise, those sites would prompt for authentication. Clicking the bookmarklet once more, would post the page to our servers.
The pros of this approach was that we never collected anyone's credentials so any concern of security would have been alleviated. Secondly, it would make it impossible for Yahoo/ESPN/CBS to block access to our service since we would never be connecting directly to their servers but rather the user's browser would be posting the contents of their browser to our server.
The problems with this is that it takes 2 clicks to post a page to our site. For head to head leagues, we needed 3-4 pages so it would take our user 6-8 clicks to sync their league to our servers. We're still looking at options for this.
One important note is that I ran into the product manager of the Yahoo Fantasy Football site at a conference a year ago. We talked about how we were getting the Yahoo data, and he confirmed that getting credentials would violate their TOS and they may stop us. While I don't think they would have, it would have made it hard to invest time and energy to develop this only to have them block our site and pissing of users by closing their accounts.
A potentially more complicated answer could possibly be done with (for example) yahoo pipes.
Hypothetically, you create a pipe which prompts the user for their credentials and provides them with a url which contains their scraped data. They enter this URL in their site, and never have to provide their credentials directly. Even better, for the security-conscious, it would be possible to examine what the pipe was actually doing before entering any information.
The downside would be increased complexity (as well as you'd have to write and maintain the pipe). Having said that, you could provide a link directly to the published pipe from your site, to make things as easy as possible.
Option 1 is the obvious choice. People who trust your site will provide the details. There is no other way you can login to other site while screen scraping.