I have an application for which I need the user have several permissions set a particular way (for example Use Location set to "Always").
My programmers are running into issues checking the "Use Cellular Data" permission. They claim there is no API to determine the status of this on a per app basis. I have followed some discussions on SO and that was true in the past. B
My question is, is there still no reliable way to determine whether a user has granted my app the ability to use cellular data?
Related
My organization set up Cloud SQL as the default for Google App Maker about one month ago. In the last week, we have been unable to preview or publish apps that use Cloud SQL data sources, including the sample applications which worked perfectly before. The failure occurs during the authorization process. When previewing or publishing an app, Google App Maker displays a dialog stating "Deploying this app requires authorization". Next it prompts the user for their Google account and then requests approval for the necessary authorizations (e.g., "Manage the data in your Google SQL Service instances"). After approving the authorization, the prompts to authorize begin over with the dialog stating "Deploying this app requires authorization".
Observations:
We have repeated this problem on multiple different computers, networks, and four different user accounts.
In the SQL cloud console, our Cloud SQL instance shows new databases being created for each app along with new database-specific user accounts
All of the databases appear as expected when I log directly into the Cloud SQL database using phpMyAdmin
Other apps which don't use a Cloud SQL datasource work fine, including an app that uses a calculated data source which is hosted in the same Cloud SQL instance
The only errors in the Stack driver logs for the Cloud SQL database showed "INFO" level communication errors with the database (aborted connection...Got an error reading communication packets)
I'm unable to find Stack driver logs for the apps because I cannot preview or publish them (either option would provide a link to the Stack driver logs)
There are now approximately 20 databases in our SQL instance (mostly associated with simple app tests) and we have only used 1 GB of 10 GB of space in our SQL instance
I haven't seen any related problems on the Google Issue Tracker for Google App Maker
I'd appreciate any help or suggestions on what to check in order to resolve this issue.
I posted an issue to Google Issue Tracker and Google corrected the problem. They also provided a workaround if this problem happens again.
Here is the response from the Google development team posted on Google Issue Tracker: https://issuetracker.google.com/issues/145345198
It's great to hear your up and working again! We are aware of this issue and are working through a longer term fix. The specific bug appears to be related to some changes made in the Google Cloud session policy control that may have rolled out to your domain recently interacting with AppMaker in a way that was not expected. We've spent time diagnosing the underlying issue and we beleive we know the root cause. I suspect your domain admin did a version of the workaround below.
Without getting too far into the details, the specific bug is that for a Deployer of an AppMaker application, if the Google Cloud Session policy is set with any expiration time, the returned token AppMaker sees is invalid, triggering a loop in AppMaker trying to generate a valid security token. Historically, these session tokens never expired but recently there was beta feature launch that allowed domain admins to set them to expire. We strongly suspect your domain recently set this expiration policy explicitly and that's what is causing the bug.
The good news is that these policies are overridable per Organizational Unit and we have tested that OUs which have the original classic Never Expire setting do, in fact, allow AppMaker to work.
My suspicion is that your domain admin has reverted recent, local changes to your organizational policy under the admin.google.com console, specifically under Security > Google Cloud session control (Beta).
If this happens again, here the workaround we would recommend. Note you don't need to do this if you're currently up and working. You will need the help of someone with admin.gogole.com powers, specifically User and Organizational Unit powers at your organization. It is a slight increase in security risk but it restores some classic behavior that was standard until recently.
The summary of the workaround is to override the Google Cloud session control expiration setting such that individuals who need access to AppMaker deployments can have it. To mitigate systemic security risk, this is best done by creating a limited purpose Organizational Unit with just that setting different than the parent OU settings.
The workaround is to:
Contact someone in your domain with Admin powers for your Google for Business license.
Have your admin proceed to https://admin.google.com. The actions below need to be performed by a domain admin.
Under the Users section, identify the specific user account that needs the ability to deploy AppMaker Apps.
Identify the Organizational Unit of that Appmaker dev user and make a note of it.
Under the Organization Units settings, locate the Organization Unit you identified above.
Create a new Organization Unit underneath that user's current Organizational Unit with some descriptive identifying it as special w.r.t AppMaker. So for Developers, make something like DevelopersWhoAreAlsoAppMakerDevs.
Back under the Users tab, locate the user from step 3. Move this user into the new Organizational Unit you've just created. This change can take a while to propagate.
-Interlude- At this point, you've made a new Organizational Unit for just that individual and added them to it. You can certainly add multiple people to that OU, especially if they're already in the same parent OU. Use your discretion as to what amount of Organizational rework you wish to pursue. You may not be using OUs at all or you may decide to just turn off this control for the whole domain. It's up to you.
Under admin.google.com's Security settings, locate the Google Cloud session control (beta) settings.
Under this panel, from the dropdown menu on the left, locate the Organization Unit you just created.
Be sure to select ONLY the OU you intend to change.
Change the "Google Cloud Console and Google Cloud SDK session control" from expiring to "Session Never Expires".
Save your changes.
The account you selected in step 3 should now be able to deploy AppMaker apps.
It appears this OU change is only necessary for the deployer of an AppMaker app, not an individual user. Note also that if you have multiple AppMaker developers who all have different current OU settings, you may need to create multiple daughter OUs to avoid a sudden radical shift in OU settings for an individual account.
Is there a way to protect the database from deletion? I mean it's very easy to click on the "x" next to the root node. This would destroy the whole app and cause an enourmous mess to deal with.
How to deal with this fragility?
EDIT:
Let's assume I have two firebase accounts: one for testing and one for the launched app. I regularly log in and out to use the other one. On the test account I delete whole nodes on a regular basis. An activated password protection would avoid a very expensive confusion of the two accounts.
If you give a user edit access to the Firebase Console of your project, the user is assumed to be an administrator of the database. This means they can perform any write operation to the database they want and are not tied to your security rules.
As a developer you probably often use this fact to make changes to your data structure while developing the app. For application administrators, you should probably create a custom administrative dashboard, where they can only perform the actions that your code allows.
There is no way to remove specific permissions, such as limiting the amount of data they can remove. It could be a useful feature request, so I suggest posting it here. But at the moment: if you don't trust users to be careful enough with your data, you should not give them access to the console.
As Travis said: setting up backups may be a good way to counter some of this anxiety.
Is there any limitation in Tridion that would stop more than one physical user sharing a single Tridion account for logging in?
Tridion as far as I know wouldn't end the other session or log a user out if both logged on at the same time, for instance.
Our client is getting close to their licence limit and is looking several users sharing a single account. From a business perspective they'll lose the ability to really know who changed what - but there's no workflow in place.
Is this in breach of the Tridion licence to do this?
Cheers
Tridion is a stateless application, so although there is authentication there is no concept of log-in or log-out. You could have problems if different users of the account tried to change the same item at the same time (have seen this in training session where a single account was used).
Yes, it would be a breach of the license conditions - typically this is done on a named-user basis, unless unlimited users were allowed (which would probably mean you wouldn't need to do this anyway).
You're right that it would probably work from the software point of view.
But I think we can guess the answer to your license question. After all, it sounds like they are looking at doing this to avoid paying money to SDL for the actual amount of users that they have.
I'm not a lawyer but that doesn't sound like a good idea...
AFAIK SDL Tridion uses sessions bound to the browser, so it doesn't matter from that point of view how many of those session use the same user account. There is no option of loggin out, or ending a session for that matter either.
So yes multiple users can use the same user account but they pose themselves a risk. If user A checks out an item and starts working with this, user B (using the same SDL Tridion account as user A) can also open that item and will not get it in read-only mode (like you would if you were using a different account). So the versioning and locking of items are now bypassed and rendered useless.
Lastly this is indeed violating the license agreement as specified in the contract (unless there is an unlimited number of users granted in the contract).
I am developing a flex 4.5 web based application and I need to make sure if the client chooses a certain level of security, each user can log only from an authorized computer.
So the question is how can I get some unique computer information? Anything like HDD serial number, CPU specifications, motherboard information, even the user that is logged into the Operating System can do.
So far the information on the web isn't giving me much hope that this can be achieved, but I had to ask.
Thanks in advance.
I suppose the only option available for web application is to create unique id from fields of flash.system.Capabilities class.
Other strategy which can be used is to generate unique UID in process of computer's authorization and then store it in local storage using SharedObject. Then web app tries to read authorization data from SharedObject on web app start. If there is no such data computer isn't authorized.
Richard is right. For security, unique identifying information is not available for applications running through Flash Player. You could write an Active X control (for IE) or a plugin (for Mozilla based browsers) to obtain additional information for your app if users (and their IT administrators) allow it. Information available will vary depending on the browser and operating system the user is running.
Adobe Air, on the other hand, allows access to additional network information including MAC address in the NetworkInfo class. Maybe it's worth considering an installed client app for users who require the additional security. Take a look at: http://www.adobe.com/devnet/air/flex/articles/retrieving_network_interfaces.html
This is not easy using a browser based Flex application, but there are some workarounds.
The browser based Flash Player can communicate with an AIR app on the desktop using localconnection. So, you could create an AIR app that utilizes NativeProcess to retrieve your machine specific information.
You could also use NativeProcess from a AIR app without using the browser at all.
A third option would be to install an application server on the client machine and have the browser based app communicate with the server to retrieve the client information.
I consider most of these options too difficult to be practical, but it depends on how important this feature is to you.
The Flash Player security sandbox will not let you read anything unique about the system on which the SWF is running, so I'm afraid this is not possible. The closest you will get is likely Capabilities.serverString along with maybe IP address, but the serverString property just lists all the capabilities of the client, which is obviously not a unique thing, and also might change from time to time for the same computer.
Warning: my knowledge of server-side scripting is limited to say the least.
This isn't a technical solution, but rather a different approach to your problem.
An alternative solution to would be to inspect the raw packet at the server in order to obtain data such as the IP and MAC address. Based on this the server can then deny or allow the login attempt.
I am used to working on embedded web servers running on micro controllers where C-based black magic is rather common, so I am not sure if this is possible or practical in a more traditional environment.
Recently i received an interview question.
How to maintain search day to day search history in an asp.net application?
Which one of the below would be the right choice?
1)Cookies 2) Sql Server 3) Session State
I guess the correct option could be Cookies.Please kindly share your thought.
SQL Server is the most reliable way of maintaining whatever. Cookies cannot generally be relied upon, and sessions expire and lose all data.
So the question boils down to: if you need to mainain long-term historical records, go with SQL Server. If you want to show what a particular user has searched for, go for session (or cookies, but they're somewhat size-limited).
All 3 options are acceptable in different scenarios for many different reasons - it's a softener question designed to get you thinking and talking:
(1) Cookies - for a per user / browser session provides a client-side solution (provided the user accepts / does not delete them) and you don't care that this can happen. However, this does tie the user to the browser. Useful for anonymous per-user browsing but not if your intention is to keep or query the history.
(2) SQL - guarantees history is saved server side but you would need a mechanism such as a client login to associate the history with the user and the only solution of the 3 presented that would allow you to perform any sort of historical multi-user analysis / analytics.
(3) Session state - not advisable - but arguably similar to cookies but without the caveat that cookie acceptance is required - however you introduce the timeout issue and again tie the user to the browser and limited lifetime of the information.