This is an extension of the below thread...

Security Review - Am I Ready?  which has this text...

"We understand that our partners are of varying sizes and may not necessarily have all the organizational security processes and policies in place. As long as your application and network security is solid and you've address issues flagged by Checkmarx and Burp, you should be in good shape."

The Requirements Checklist provides a number of security points including specific application password handling (enforcing password expiration, etc). 

For a hosted application, I am curious how much these policies are enforced, or if they are largely recommendations.  We are a small team and have not yet implemented all of these points, but have locked down our application with other standard means.

If we focus on Burb and Checkmark security scans will we be pretty much ok? (I have another post about FLS being a concern since we are integrating only per the API).

I'd hate to spend the time and money waiting for the review only to be rejected for one of these points. Anyone have any insight?

Thanks!

Reilly

We are submitting our composite ("mashup") application app for security review and have seen several references to FLS (Field Level Security) requirements.

Our integration is solely throught the API - there is no APEX code, native integration, etc.

I have seen in several places that Field Level Security (FLS) is enforced at the API level fro hosted applications. For example...

http://boards.developerforce.com/t5/Security/Field-level-security/m-p/184716/highlight/true#M164

The API will enforce all Sharing, CRUD, and FLS settings of the current user.  Apex With Sharing mode will NOT enforce FLS by default.

http://boards.developerforce.com/t5/Security/Integrating-Web-Applications-with-SFDC-using-OAuth/m-p/172660/highlight/true#M10

At runtime, when an access token is negotiated for a consumer that belongs to a managed package, the access token is scoped to the user's Org, with the CRUD/FLS permissions of theuser as well as the package access permissions granted upon installation being enforced.

We are only working with common objects (Contacts, etc) – that would likely not be restricted on any given account. 

Do we need to take this into account? Or can we rely on the API layer to enforce this for us?

Thanks,

Reilly

We are considering entering the hackathon, but the below criteria provides for some interesting grey areas: 

The application you or your team submits must...
...have been developed solely as part of this Hackathon 

For example:

• Can we re-use code we have written for another related product?
• I know we can use open-source libraries and APIs, but what about an API to our own pre-existing product?
• What if we were want to modify an existing project to be an entrant into this Salesforce contest?
• Lastly, what if someone had the idea or started tinkering with it a year ago, but now wants to finish it in the hackathon?

Sorry for the baragge of questions...the word "solely" is just so absolute. Most people who are entering this have probably done some work on their idea apart fro this hackathon.  My question is how much "prior work" or "non-hackathon" work is acceptable?

ps – This is a continuation of a comment thread here – I thought it warranted its own thread after considering it further.

This is an extension of the below thread...

Security Review - Am I Ready?  which has this text...

"We understand that our partners are of varying sizes and may not necessarily have all the organizational security processes and policies in place. As long as your application and network security is solid and you've address issues flagged by Checkmarx and Burp, you should be in good shape."

The Requirements Checklist provides a number of security points including specific application password handling (enforcing password expiration, etc). 

For a hosted application, I am curious how much these policies are enforced, or if they are largely recommendations.  We are a small team and have not yet implemented all of these points, but have locked down our application with other standard means.

If we focus on Burb and Checkmark security scans will we be pretty much ok? (I have another post about FLS being a concern since we are integrating only per the API).

I'd hate to spend the time and money waiting for the review only to be rejected for one of these points. Anyone have any insight?

Thanks!

Reilly

Having the hacker pass is enough?  or do I need to have a pass to dreamforce in addition?

We are considering entering the hackathon, but the below criteria provides for some interesting grey areas: 

The application you or your team submits must...
...have been developed solely as part of this Hackathon 

For example:

• Can we re-use code we have written for another related product?
• I know we can use open-source libraries and APIs, but what about an API to our own pre-existing product?
• What if we were want to modify an existing project to be an entrant into this Salesforce contest?
• Lastly, what if someone had the idea or started tinkering with it a year ago, but now wants to finish it in the hackathon?

Sorry for the baragge of questions...the word "solely" is just so absolute. Most people who are entering this have probably done some work on their idea apart fro this hackathon.  My question is how much "prior work" or "non-hackathon" work is acceptable?

ps – This is a continuation of a comment thread here – I thought it warranted its own thread after considering it further.

When can we start building our app? October 25? (Hackathon Registration) OR November 18 (Dreamforce)?

Does anyone know if we have API access to "Unresolved items" in particular, the events.... is there anyway I can create a lookup to someone else's "unresolved items"?

any help on this topic would be appreciated...!